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

STOP THE PRESSES Re: XFree86 4.0.2-12 release and architecture status

[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

So, the X library packages on i386 can't be compiled against until further

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: pgpIqJzK829XI.pgp
Description: PGP signature

Reply to: