[Re-sending to the bug rather than the debian-policy@ list, sorry for the duplicate delivered to list subscribers]

On Wed, 07 May 2025 at 13:48:19 +0100, Ian Jackson wrote:
Rebuilds are arch-specific, so the binNMU
number can vary across architectures, just as the bdate can:
 https://packages.debian.org/sid/libopts25-dev

They can, but according to the rules applied by dpkg/apt for multiarch,
instances of the same binary package with a different version number are not eligible for co-installation, even if they are both M-A:same, so it's OK for their contents to be different.

(Concretely, if you have a hppa foreign architecture on your amd64 system, you can't install libopts25-dev:amd64=1:5.18.16-5+b2 and libopts25-dev:hppa=1:5.18.16-5+b1 at the same time.)

Various developers (ask the release team to) schedule binNMUs to align release architectures' ma:same package versions where necessary, especially during the soft freeze. I see that libopts25-dev is at 1:5.18.16-5+b2 on all release architectures, so this has presumably been done.

For -ports architectures, it's up to the port maintainers to either keep up with the binNMUs of release architectures or decide that multiarch co-installation is not sufficiently important for the port.

    smcv

Reply via email to