unsubscribe
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: