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


On 7/16/05, Steve Langasek <vorlon@debian.org> wrote:
> 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
> trouble.
> Cheers,
> --
> Steve Langasek
> postmodern programmer
> [1] http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html
> BodyID:17829889.2.n.logpart (stored separately)

Reply to: