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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
