After a binNMU, the individual architecture built packages don't migrate
all at once but one after the other as soon as they are available. This
breaks setups with foreign architectures in a short time window.
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1123533#15 :

| # apt-get install libssl-dev:arm64
|
| The following packages have unmet dependencies:
| libssl-dev:arm64 : Depends: libssl3t64:arm64 (= 3.5.4-1) but it is not going to be installed
| E: Unable to satisfy dependencies. Reached two conflicting decisions:
| 1. zlib1g:arm64 is not selected for install because:
| 1. dpkg:amd64 is selected for install
| 2. dpkg:amd64 PreDepends zlib1g (>= 1:1.1.4)
| 3. zlib1g:amd64 is available in version 1:1.3.dfsg+really1.3.1-1+b1
| 4. zlib1g:arm64 Breaks zlib1g (!= 1:1.3.dfsg+really1.3.1-1+b2)
| 2. zlib1g:arm64 is selected for install because:

In this case arm64 was available before amd64 was. I don't know what
exactly the policy is but it looks that the bunNMU version (+b?) is kept
consistent for all architectures to avoid this scenario.

Would it be doable to teach britney to migrate all packages together to
testing instead one by one?

Sebastian

Hi,


binNMU's may be architecture specific, so in general it won't be good to
assume all architectures are coming. An idea (haven't though long about
it): maybe we could wait for sources where at least one of the binaries
is MA: same, as there the binNMU *should* be scheduled on all architectures.

Paul

Hi,

That makes sense. In zlib's case the binNMU was scheduled due to
something arm64 specific and it was scheduled on all architecures.
For MA=same you need the same version to allow co-installation so a
binNMU should be scheduled on all achitectures.
You don't need to the same version for MA=foreign or MA=allowed so a
binNMU could be skipped there.

Sebastian