Hi, indeed I forgot about multiarch... and I ment that non-installibility is a bug for sure (though just a sympton of the real bug), but often packages can still be installed even though the versions of a package differs due to binNMUs. Andway - more to the point: (leaving full context for the benefit of Ralf whom I added to cc:ed..) On Samstag, 1. November 2014, Wookey wrote: > +++ 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. Ralf, does DOSE already detect such inconsistencies or how hard would it be to add support for that? (also, btw, I couldn't find the daily DOSE runs linked from tttps://qa.debian.org/dose - did I miss it or is it missing?) > 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. I agree that a systematic fix is in order, I just wonder whether it's more reasonable to defer that for jessie+1... cheers, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.