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
