+++ Marc Glisse [2014-11-01 11:45 +0100]: > Hello, > > 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 way. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141101141901.gt28...@stoneboat.aleph1.co.uk