On Fri, Mar 27, 1998 at 04:44:22AM -0500, Branden Robinson wrote:
> All right. That's what I'm going to do, then. I had a feeling that would
> be it.
>
> Anyone who thinks this solution is an abomination in the sight of the Lord
> is welcome to file a bug against XFree86 3.3.2-3 whenever I release it. :)
Sorry to be generating all the noise, folks, but I just thought of a
better solution.
Similar to the manpages problem is the XF86Config problem. xbase doesn't
need it, its example, or its manpage, but all the X servers do.
My solution to XF86Config and X server manpage issues:
Make a new package, xserver-base, on which all xserver packages depend,
which contains:
/usr/X11R6/bin/xf86config
/usr/X11R6/man/man1/XF86_Accel.1x.gz
/usr/X11R6/man/man1/xf86config.1x.gz
/usr/X11R6/man/man5/XF86Config.5x.gz
/usr/doc/xserver-base/README.Debian (to be written)
/usr/doc/xserver-base/examples/XF86Config.eg
The xserver packages will ship with their own manpages, which will contain
the .so link to the manpage provided by xserver-base (except for the
servers mono, vga16 and svga, which will ship with a normal manpage).
Advantages:
1) People who want an xserver, and JUST the xserver, thank you, can get the
manpages and xf86config program without having to install the massive xbase
package.
2) Fixes a bunch of niggling policy violations/lintian errors, and seems
much more elegant to me.
Issues:
1) Strictly speaking, while users of those unaccelerated servers will
need the xserver-base package, the XF86_Accel manpage will be useless to
them. But I'll be damned if I'm going to make an "xserver-accel-base"
just to hold that one manpage. I'm willing to waste 10334 bytes of
space on the drives of xserver-{mono,vga16,svga} users. Good judgement or
not?
2) I am not an xdm guru, and I don't know what (if anything) would be
necessary to move into xserver-base to handle XDMCP sessions. Or would
such people need xbase anyway? I've never personally configured a Linux
machine that ran it's own xserver without also running some clients locally
as well, so I need to know what I need to do make it possible to eliminate
xbase entirely for some scenarios where that would be the case (no local X
clients). I must assume such scenarios exist, else why haven't the X
servers depended on xbase all along?
3) xbase ships with a symlink /usr/X11R6/lib/X11/XF86Config ->
/etc/X11/XF86Config . However, /etc/X11/XF86Config is not guaranteed to
exist when the package is installed (if the user doesn't accept the
postinst's offer to run xf86config, for instance). I think it's nasty to
ship a broken symlink, and I was going to have the postinst make the
symlink if and only if xf86config created one, but this has two problems:
a) at least one developer feels that anything in /usr should be shipped,
broken symlink or not; I didn't hear his justification for this, but I
generally trust his judgement.
b) Just because xf86config doesn't buld an XF86Config file doesn't mean
the user isn't going to have one -- he/she may have a known good one ready
to move into place, and they shouldn't have to make the symlink manually.
Suggestions?
Unless met with strenuous protests from many quarters, I plan to have this
in XFree86 by hamm release time. I can't guarantee that it will make it
into -3, which will probably be released sometime this weekend.
The above message is a sample of the kind of tasks the X Strike Force will be
designed to handle. If such issues get your blood pumping, I invite you to
mail me and express your interest.
--
G. Branden Robinson | If a man ate a pound of pasta and a
Purdue University | pound of antipasto, would they cancel
branden@purdue.edu | out, leaving him still hungry?
http://www.ecn.purdue.edu/~branden/ | -- Scott Adams
Attachment:
pgp481nq9eRsV.pgp
Description: PGP signature