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

[Nathanael Nerode <neroden@twcny.rr.com>]

Steve Langasek wrote:

> On Mon, Oct 31, 2005 at 02:54:49PM -0500, Nathanael Nerode wrote:
>> The enormous ABI transitions have been particularly hard, of course.  If
>> we can avoid ABI-breaking transitions in the future it would help.  :-)
> 
> Wholly unrealistic.  Libraries *do* undergo ABI changes; there are only a
> handful of library upstreams who know how to write a library interface
> that's proofed against future design decisions, and in most cases it's not
> worth the effort to try to write libs this way
Perhaps I didn't make myself clear.  I wasn't actually thinking of those,
since those can be handled quite nicely: if the library changes soname and
the symbols are versioned, both old and new versions can (and should)
coexist in separate packages and such transitions generally move pretty
smoothly (albeit slowly due to absent maintainers and lack of NMUs, which
is a different problem -- there simply should not have been that many
packages still depending on libpng10 when it was removed.)  

(At least for libraries with more than a few reverse depends; for those with
very few, they and their reverse depends can comfortably be pushed in
simultaneously if there's some maintainer coordination on lib transitions.)

> -- and it wouldn't save us 
> from C++ ABI changes anyway.
Now *that* was the sort of ABI change I was hoping we could avoid having
every release.  A major C ABI change would be even worse.

>> I think making a queue for transitions, so that they're basically one at
>> a time, would solve most remaining problems.
> 
> Doesn't work when lib maintainers don't coordinate.
Well, indeed, which was kind of, um, what I just said.  "Making a queue for
transitions" is a subset of "lib maintainers coordinating".

> A better option is to make britney more resilient in dealing with library
> transitions by keeping old binary packages around in testing instead of
> requiring them to be removed at the same time as the new version enters,
> which removes the need for all packages to be ready to enter testing at
> the
> same time.  This has been on the TODO list since it was discussed this
> past March in Vancouver, and is currently the top item on Anthony Towns'
> britney hacking list at <http://www.erisian.com.au/market/>.

The old source packages have to remain on the servers too in order to
satisfy license requirements; hope someone noticed that.

(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.)

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)
* when it Conflicts: with the old, giving the same result (hence different
sonames; also different ports for different wire protocols, etc.)
* or when both can end up linked into the same binary with conflicting
symbols, causing crashes and misbehavior (hence versioned symbols)

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'.  In most cases,
fixes for all three of these problems, as noted, can be done right now,
without any britney support, by package maintainers, or at least by
upstream.  And if they are done, they remove much if not all of the
motivation for the britney changes.

So I guess I'm saying I'd rather concentrate on versioned symbols, proper
soname handling, and supporting coexisting old and new versions for heavily
used libraries; this will make more difference than any change in britney.

And when that doesn't suffice, library maintainers need to coordinate with
the release team.

-- 
ksig --random|