[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
