Re: X Strike Force X.Org X11 SVN commit: r317 - in trunk/debian: . patches
On Wed, Jul 06, 2005 at 03:39:34PM -0400, Nathanael Nerode wrote:
> I'll help you. :-)
Much appreciated :-)
> xorg-x11 apparently doesn't build-depend on any external C++ libraries
> except libstdc++, which makes this rather straightforward.
>
> Of the library packages, only xlibmesa-glu depends on libstdc++. In fact,
> it's the only C++ package in the entire xorg tree.
> xlibmesa-glu
> -- This will need a new package name. It has a really weird package
> name right now, so that's good anyway. Ubuntu used libglu1-xorg, which
> sounds good to me. :-)
> -- And the new package will need to Conflicts:/Replaces: with the old
> package.
> -- Ubuntu also made this "Provides: libglu1c2" instead of "Provides:
> libglu1". This makes sense since there are alternative
> providers of libGLU.1.
> xlibmesa-glu-dev
> -- A new name is desirable because we're cleaning up the package
> name. Probably Conflicts:/Provides:/Replaces: in this case.
> Ubuntu used libglu-dev-xorg, which sounds good to me.
I spoke with Daniel, and he plans to use libglu-xorg-dev, which seems right
to me. He plans to fix this in the near future for Ubuntu, so let's just go
with it from the start.
> xlibmesa-glu-dbg
> -- Likewise, new name and Conflicts:/Replaces:. Ubuntu used
> libglu1-dbg-xorg, which sounds good to me.
Again, let's go with libglu1-xorg-dbg.
> This migration was done in Ubuntu's 6.8.2-11. Along with gobs of other
> stuff, of course.
>
> xlibmesa3 (transitional package) depends on xlibmesa-glu
> xlibmesa-dev (transitional package) depends on xlibmesa-glu-dev
> -- These two should IMNSHO just be dropped, since direct upgrades from woody
> to etch aren't supported anyway IIRC. Ubuntu kept them, but I don't know
> why.
Fine by me. We've got enough cruft in the tree already :-)
> xbase-clients depends on xlibmesa-glu
> x-window-system-core (metapackage) depends on xlibmesa-glu and xbase-clients
> x-window-system-dev (metapackage) depends on xlibmesa-glu-dev
> -- these will have dependency changes only
>
> The remaining packages depend only on program packages, not library
> packages, but I list them anyway just in case:
>
> xdm depends on xbase-clients
> x-window-system (metapackage) depends on xdm
> xprint-common (from xprint) depends on xbase-clients,
> and xprt depends on xprt-common
> -- Incidentally, the xprint dependencies are *broken* in the current tree,
> since xprint-common doesn't provide xprt-common.
> xprt should "Depends: xprint-common | xpt-common", I think.
>
> That's it for the actual ABI transition. GCC4 build fixes may also be
> needed.
>
> > Daniel and Ubuntu have already made the transition, and
> > if it doesn't involve very much then we can get it done quickly.
>
> I believe he's included a number of GCC4 build fixes, some of which may be
> needed.
Yeah, I've already stumbled across one problem building packages. I'll be
testing and pulling patches from the current breezy packages as need be to
get our tree working with gcc4.
> > After that, I'm going to get approval from the release team for the actual
> > upload.
>
> First we should review the packages to make sure they're all
> (a) installable in unstable -- the xprt-common thing would suck
I tested the original batch in unstable, but more testing is good. I don't
want to delay for testing too long though.
> (b) haven't had large accidental manifest changes (debdiff)
When I was reviewing the manifests ages ago, I took note of all the
removals, and basically everything is accounted for. If someone wants to do
this and make sure I didn't miss anything, feel free.
> (c) haven't had accidental soname changes (which would really cause trouble;
> debdiff again)
Ok, good idea. Once we have a tree that fully builds with gcc4, I'll begin
the C++ transition changes (patches happily encouraged, as ever) and we can
finish the final stretch.
- David Nusinow
Reply to: