On 03.09.20 21:38, Helmut Grohne wrote: > Package: buildd.debian.org > > When binNMUing a package, the time of the build is used for creating the > changelog entry. This is an sbuild default due to #843773. That results > in SOURCE_DATE_EPOCH not being equal for those builds and some tools > embed that timestamp into packages for shared files. Doing so can result > in unpack errors, when the relevant binary packages are marked > Multi-Arch: same. An example package is libtie-hash-indexed-perl and it > happens to break due to binNMUs being performed on different dates. > > On the sbuild side, the idea is that you pass --binNMU-timestamp=... > Unfortunately, it's not so easy on the wanna-build side as you can > schedule a binNMU at any time. What makes matters worse is that each > binNMU is scheduled individually and locks tables individually in that > process (according to Aurelien Jarno). So while wanna-build could pass > that flag to sbuild, it's not easy to produce an equal value for all > binNMUs of a source package. Picking closer dates would have avoided the > issue with libtie-hash-indexed-perl. > > Does anyone else see more options for solving this?
My personal opinion always has been to mimic what Ubuntu does with sourceful +build uploads. It would avoid us chasing down every single difference that binNMUs cause. The current system is mostly a result of the wish of doing per-arch binNMUs which is really not the primary purpose of the system anymore. But alas, changing this has not been politically viable in the past - because source uploads are treated so differently by the archive, builders are not allowed by the archive to upload them and because they'd culturally be treated as NMUs instead of updates for internal, technical reasons. I also hate the per-architecture DB structure of wanna-build and consider it a mistake. But then to do things sanely you'd need a middle service doing permission checking. Technically the Release team mostly uses "wb" as a wrapper and we could plumb through a timestamp - as long as all binNMUs are scheduled in one invocation, which should be mostly (but not always) true. In any case it feels like if we want this invariant to hold we also need archive-wide monitoring to ensure it. That said, I know Guillem held in the past that the invariant people rely on here is more by accident than being intentional - and that co-installable MA:same packages should not be supported ([1]). Kind regards Philipp Kern [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#132
signature.asc
Description: OpenPGP digital signature
