On Tue, Nov 01, 2005 at 02:49:27PM -0500, Nathanael Nerode wrote: > (Hmm, I wish there was a way there to pay him to change the priorities > -- what britney needs most is proper version tracking support for its RC bug > analysis, and I'd give some money for that; that's not listed in the notes > for 'next round of version tracking support' under debbugs either.) No; proper version tracking in britney is *much* less important than fixing how we do library transitions. We have other means of tracking RC bug counts in testing and can easily override britney's concept of package bugginess if necessary, but library transitions are a major, and currently unavoidable, time sink for the release team. > Anyway, such a change won't do anything to help the people trying to install > 'testing' > * when the new library uses the same package name as the old, so users can't > install packages depending on the old and the new at the same time > (hence different package names) which is rare; apt is the only package I know which does this for legitimate reasons. > * when it Conflicts: with the old, giving the same result (hence different > sonames; also different ports for different wire protocols, etc.) which is an issue for C++ ABI transitions, but the C++ ABI transition was not the only reason for this transition to be so difficult -- the KDE change wouldn't have been half as difficult if it had not been connected to a number of other, unrelated soname changes. > * or when both can end up linked into the same binary with conflicting > symbols, causing crashes and misbehavior (hence versioned symbols) which is a bug in those libraries that causes breakage on partial upgrades, and we should fix this regardless of what happens to britney. > If these issues aren't fixed, britney changes will just make 'testing' more > broken; imagine having two wire-incompatible binary packages of JACK, > trying to run on the same port, available in 'testing'. No, this would not involve keeping multiple versions of the same binary package in testing; there would be no way to install the older versions anyway. We're only talking about keeping old binary packages around which are no longer available from the new source package, which is precisely the case that is at issue with library transitions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature