Re: Truncated changelog leads to file conflict with MultiArch: same

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
>