On 2026-05-17 20:49:56 +0200, Gioele Barabucci wrote: > On 17/05/26 15:08, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > > > Quoting Gioele Barabucci (2026-05-17 14:14:51) > > > * The only solution to this problem is that 1) all buildd chroots must be > > > updated at the same time, and 2) all binNMU must run inside the same > > > dinstall > > > window. Otherwise there will always be the risk of package version skew > > > and > > > M-A issues. > > > > synchronizing start times to the dinstall window is not sufficient. buildds > > use > > https://incoming.debian.org/debian-buildd as an additional mirror. > > Depending on > > how fast the same package builds on each architecture, that mirror > > frequently > > carries different package versions for different architectures. > > Someone on IRC (sorry, I forgot who) suggested that all binNMU could run > using a snapshot of the archive at the time the binNMU has been requested (à > la debrebuild). This would in fact simulate having all binNMUs running > inside the same dinstall window.
While we most often only see this issue with binNMUs, the problem is not unique to binNMUs. Even for builds of sourceful uploads the problem of changes in dependencies exists. Just think of a package being BD-Uninstallable on some architecture due to a dependency which at some point gets fixed. Or well, a new architecture being bootstrapped where packages may be built years after they have been last built on oder architectures. Cheers > > So one possible solution would be: > > * All buildd chroots are generated at the same time and are ensured to have > no version skew. > > * A mechanism ensures that the "request time" for a set of binNMUs is > recorded and passed to all arch-specific buildds. > > * The dependencies of binNMUs are not fetched from the normal archive, but > from a snapshot of the archive taken when the binNMUs are requested. > > * The snapshot does not only take the normal archive into account, but also > incoming.d.o. (Is this already the case?) > > Unfortunately, automating all this requires extra infrastructural code that > does not exist, IIUC. > > Regards, > > -- > Gioele Barabucci > -- Sebastian Ramacher
