Hi folks.
As some of you know, highly unstable and experimental 4.0.1 .debs were
produced on Friday and made available to a few people for testing. These
things were way broken, but not as badly as I feared. I got some valuable
feedback, made some fixes, and am preparing for a real Phase 1 release as I
write this.
But XFree86 4 has thickened the plot in a way I didn't foresee.
It has to do with app-defaults files. Current Debian policy says these
can't be conffiles, so they go in /usr/X11R6/lib/X11/app-defaults.
Well, upstream has changed things, and it putting them in
/etc/X11/app-defaults. Rather than buck this trend, I think we should roll
with it.
However, this means changing Debian policy. That part's not hard.
(Unless the -policy group wants to prove me wrong on this point.)
What's worse is that /usr/X11R6/lib/X11/app-defaults is going to need to
become a symbolic link to /etc/X11/app-defaults, and because dpkg does not
clobber directories by overwriting them with symlinks (rather, it just
fails to make the symlink), a *LOT* of packages are going to have to change
the way they do things. So, the current app-defaults policy is going to be
taken out back and shot.
Things will break spectacularly if that symlink doesn't exist. So it HAS
to be there. So here's what I'm going to do.
We all know there is a "root" XFree86 package that all other X Window
System packages depend on, and that is xfree86-common. In the preinst of
this package will be something like the following logic:
if [ ! -L /usr/X11R6/lib/X11/app-defaults ]; then
# uh oh, we need to move this
mv /usr/X11R6/lib/X11/app-defaults /usr/X11R6/lib/X11/app-defaults.MOVING
ln -s /etc/X11/app-defaults /usr/X11R6/lib/X11/app-defaults
mv /usr/X11R6/lib/X11/app-defaults.MOVING/* /etc/X11/app-defaults
rmdir /usr/X11R6/lib/X11/app-defaults.MOVING
fi
dpkg-divert doesn't make a lot of sense here because the files will be
resolvable using same path they were before --- AFTER the preinst has done
its work. Since only one preinst runs at a time, and this preinst handles
the whole migration, this is an atomic operation from the package system's
perspective.
*HOWEVER*, dpkg's databases will contain bogus information about the
locations of files installed to that directory. So it is imperative that
these packages have new versions that will clean up the mess.
All these new packages have to do is ship those app-defaults files in
/etc/X11/app-defaults instead. I suggest marking them as conffiles as
well, but this is ultimately up to the package maintainer's discretion.
So here is what I suggest. Packages that currently ship app-defaults
files MUST, when they are built against xlib6g 4.0.1, implement this
transition. This will make everything as clean and neat as it can be
because:
+ All packages that ship stuff in /usr/X11R6/lib/X11/app-defaults are X
clients.
+ X clients depends on the X libraries. (Exceptions to this in the Debian
system do not exist in practice, unless we have any programs written in
Common Lisp and using CLX. I don't think we do.)
+ Since X clients depend on X libraries, and since this transition is being
implemented over a major version number change, we get the following
effect:
The app-default using package depends on xlib6g (>= 4.0.1-whatever)
just as xlib6g's shlibs file will tell it to.
xlib6g 4.0.1 will depend on xfree86-common 4.0.1, which, as described
above, will implement the transition if there is one to be made.
So, if you make the app-defaults change at the same time as you rebuild
your package against the forthcoming 4.0.1 xlib6g-dev, you will not have
any trouble. In fact, I will add some noise to the above script to
identify the files being so moved so that everyone sees what packages might
need to be fixed.
Here's the list of packages that need to change. It *might* not be
exhaustive; I think this list is only good for potato, and not woody. Yes,
some of them are mine. Those are part of XFree86 and transition
appropriately.
Thanks to Joey Hess for generating this list.
admin/dialdcost
comm/seyon
comm/xtel
contrib/utils/xwatch
devel/ddd
devel/lesstif-bin
devel/xmpi1-runtime
devel/xxgdb
editors/sam
editors/sex
editors/wily
electronics/nitpic
electronics/pcb
electronics/xcircuit
games/jnethack
games/kdrill
games/nethack
games/xbl
games/xblast
games/xbomb
games/xconq
games/xcruise
games/xemeraldia
games/xgammon
games/xonix
games/xonix-jahu
games/xpat2
games/xsok
games/xtron
graphics/pixmap
graphics/xbmbrowser
graphics/xfig
graphics/xpaint
graphics/xpcd
hamradio/twclock
hamradio/twlog
hamradio/xconvers
mail/coolmail
mail/xbuffy
mail/xfaces
mail/xlbiff
mail/xmailbox
mail/xmailtool
mail/xmh
math/felt
math/xmgr
misc/titrax
net/isdnbutton
net/isdnutils
net/xftp
net/xnetload
news/knews
non-free/editors/axe
non-free/games/xearth
non-free/games/xinvaders
non-free/games/xtrojka
non-free/graphics/tgif
non-free/misc/mpsql
non-free/misc/xephem
non-free/net/epan
non-free/web/chimera
non-free/x11/cxterm-common
non-free/x11/xarchie
non-free/x11/xpostitplus
non-free/x11/xtoolplaces
sound/awe-midi
sound/mctools-lite
sound/mixviews
sound/playmidi
sound/rosegarden
sound/snd
sound/xmcd
sound/xmix
tex/bibview
tex/tetex-base
text/ghostview
text/gv
text/mgdiff
text/wordnet
text/xless
utils/procmeter
utils/xdu
utils/xosview
utils/xsysinfo
web/vrweb
x11/hanterm
x11/kinput2-common
x11/kterm
x11/skkinput
x11/swisswatch
x11/xawtv
x11/xbanner
x11/xbase-clients
x11/xcalendar-i18n
x11/xcolors
x11/xcolorsel
x11/xdm
x11/xipmsg
x11/xkeycaps
x11/xmaddressbook
x11/xmem
x11/xmotd
x11/xpaste
x11/xrn
x11/xruskb
x11/xscreensaver
x11/xscreensaver-gl
x11/xsm
x11/xtartan
x11/xterm
x11/xvncviewer
P.S. X resources and app-defaults are different things. I'll come up with
a description of how when I draft a policy proposal to replace the existing
one about them.
--
G. Branden Robinson | Q: How does a Unix guru have sex?
Debian GNU/Linux | A: unzip;strip;touch;finger;mount;fsck;
branden@deadbeast.net | more;yes;fsck;fsck;fsck;umount;sleep
http://deadbeast.net/~branden/ |
Attachment:
pgp1FbyeEFmcH.pgp
Description: PGP signature