Re: inconsistent versions of M-A: same packages
+++ Marc Glisse [2014-11-01 11:45 +0100]:
> sorry for the naive question, but is there a plan for massively
> rebuilding all "Multi-Arch: same" packages that have inconsistent
> version numbers across architectures before releasing Jessie?
I don't know, but I think there should be. Thank you for bringing this
up. As you say, currently this is the only way to make multiarch
co-installability work properly.
I am happy to spend some time scheduling rebuilds to resync all arches
to whichever number is highest. This problem will have been made worse
by the late-in-the-cycle additions of arm64 and mips64el (despite some
effort being made to avoid library binNMUs when there was a choice,
specifically to minimise the size of this issue) so it's only fair
that us porters take the time to fix it up.
The problem evaporates when new source versions are uploaded, and I
expect there will be a fair amount more of that before release time
due to bugfixes. So I expect the release team have an opinion about
the most appropriate time for deciding that some 'version sync only'
rebuilds should be scheduled to fix remaining library-version mismatches.
It is currently a feature of our bootstrap/import process that we do
binNMUs of packages (to rebuild packages originally imported from
debian-ports to break cyclic dependency loops on the 'kosher' buildds,
or to rebuild profile-built bootstrap packages). And some of these
imports have to be library packages, so this issue inevitably
arises. Before multiarch this didn't actually matter. They are also
heavily used for library transitions where arches have different sets
of packages built against an old library (and thus need rebuilding to
get rid of the old version).
Changes to the system such as a mechanism for rebuilds that didn't
change the version number, or changes to dpkg to consider binary
rebuilds 'multiarch equivalent' would solve this in a more systematic
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM