[sorry for the wide CC; please note the Reply-To header] Predictably, my efforts to create a synchonization point for XFree86 blew up in my face. So, alpha, arm, and m68k, *stop the presses*. You can build this version, but it's going to be a little buggy, and it will not be the last one you have to build for a while. There will be a 4.0.2-13. 1) 4.0.2-12 for i386 is broken. Just building against libc6 2.2.2-2 is insufficient to avoid the gcc/binutils problem that BenC warned about in debian-devel. So, the X library packages on i386 can't be compiled against until further notice. 2) There is a problem with app-defaults migration. Packages that ship /usr/X11R6/lib/X11/app-defaults, *but no longer exist* create a file overlap. So far I know of only one package fitting that description: xmh (part of XFree86 3.3.6). There are a few ways to solve this problem: 1) xlibs can Replaces: every such package The problem with this approach is that I don't yet know the entire list of packages with the same problem as xmh. Some scriptage involving the potato and sid Contents and Packages files would probably help, but if more app-defaults using packages from potato vanish before woody is released, the problem comes back. Keeping up with this moving target is not an appetizing prospect to me. 2) xlibs can stop shipping /usr/X11R6/lib/X11/app-defaults (which is a symlink) and just create it in its postinst, and remove it in its prerm, just as we do with /usr/doc -> /usr/share/doc 3) We can do either of the above, but move the solution to the xlib6g package. Potato X clients are guaranteed to depend on xlib6g, so this package will get upgraded. Also, xlib6g will go away in the woody+1 release of Debian, as will the need for this compatibility symlink. (Actually, in theory since all still-living packages that use app-defaults have now made the transition to /etc/X11, I can get rid of the symlink right now. But I want to keep it around so that things don't get screwed up in odd situtations, e.g., a person downgrades to the woody version of a package, or a maintainer whose app-defaults using package was NMU'ed to effect the transition reawakens from death and does a maintainer upload which backs out some/all of the NMU bug fixes, since he was not properly coddled and stroked by the person doing the NMU [see debian-devel for a discussion of this subject].) I'm tempted to go with solution 2) because it is the least effort. Here's your chance to express your opinion on this subject. -- G. Branden Robinson | You live and learn. Debian GNU/Linux | Or you don't live long. branden@deadbeast.net | -- Robert Heinlein http://deadbeast.net/~branden/ |
Attachment:
pgppbM_dBu2Qx.pgp
Description: PGP signature