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

Procedure reminders on updating a lib package for a C++ ABI change

As a result of some questions on IRC and some ill-timed uploads that I've
seen, I think it would be a good idea to highlight a couple of important
points from Matthias's transition plan for the benefit of library
maintainers and would-be NMUers:

The library package renames, libfoo1 -> libfoo1c2, libfoo1c102 -> libfoo1c2,
or libfoo1c102 -> libfoo1, are done because there is an ABI change *without
an upstream soname change*.  Since there is no soname change, the files
installed by the renamed package will also not change -- which means, just
like for any other packages with overlapping files, you *must* conflict with
the previous library package name.  You must *not* add a Provides: libfoo1
or Provides: libfoo1c102 to the new package; this transition is happening
because of an ABI transition, which means the new package will NOT provide
the same interface as the old one, and setting Provides will lead apt to
give your users broken package combinations.

If one of your packages needs to be transitioned, DO NOT upload it before
the C++ libraries it depends on have successfully made the transition.
Barring exceptional buildd delays, you should wait until your
build-dependencies have been rebuilt for g++ 4.0 on *all* architectures
before uploading your package.  Otherwise, you'll cause unnecessary churn on
the buildds, and it will take *longer* for your package to get built
everywhere.  Being impatient now will mean a longer wait later.  A useful
interface for tracking the status of a package across architectures can be
found at <http://people.debian.org/~igloo/status.php>.

If any of what I've said above surprises you, then you should go back and
read the complete email about the transition plan[1] before uploading
anything.  If you have questions, /ask/.  Five minutes asking/answering a
question now can easily save us weeks of fighting to get a package back into
releasable shape.

Also, for those who aren't aware, the new xorg packages now in unstable are
also implicated in the C++ transition, because libGLU is implemented in C++.
Particularly if you have packages that are involved in other transitions
that are happening right now, it may not necessarily be a good idea to
rebuild against xorg just yet unless you're already part of the C++
transition.  If you do, your package will also get tangled in the same C++
transition.  This has unfortunately already happened with GNOME, because of
a maintainer who was in a hurry to update his build dependencies for xorg;
all of GNOME 2.10 is now held out of testing until xorg is also ready to go
in, even though xorg has so far only been built successfully on 4/11
architectures.  In effect, this means all of the large etch transitions are
now hooked together, but if you have other packages that aren't yet part of
the tangle, ask before you upload and maybe you'll save yourself some

Steve Langasek
postmodern programmer

[1] http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html

Attachment: signature.asc
Description: Digital signature

Reply to: