[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...



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


Reply to: