[Please followup to <debian-x@lists.debian.org>.] The clamor for a small package containing just what you need to get the X server started is becoming a roar in the wake of XFree86 4.x, where Mesa-enabled X clients -- with their concomitant library dependencies -- are part of xbase-clients.
Some people, with justification, don't want or need all this ancillary
stuff when all the really need is startx and xauth (and sometimes just
xauth).
Therefore, I propose to split off xauth, startx, and xinit from
xbase-clients into a new package called "xinit". The
x-window-system-core metapackage will depend on it, and retain its
existing dependency on xbase-clients, though I could possibly be
persuased to move xbase-clients over to x-window-system from -core if
the xinit package is implemented.
Advantages of a new "xinit" package:
1) People who don't need Mesa libraries, etc., won't get them.
This saves space.
2) It's as much of a client-side as people using things like "X
-indirect" are likely to need.
3) People *keep* filing bugs about how bug xbase-clients plus
its dependencies are, and this should satisfy some of them.
4) Should be convenient for users who have standardized on, say,
the KDE, GNOME, or XFce environments and have no need for the
miscellaenous Athena apps in xbase-clients.
Disadvantages of a new "xinit" package:
1) Yet Another New X Package to keep track of.
2) Anybody who manages to not have the metapackages installed,
and gets xinit but not xbase-clients, may end up wondering
where that stuff is, and will file bugs instead of RTFM'ing.
3) People will probably be complaining for new things to be
put in it. Like, say, "xset". However, everything that xset
does is accessible through X protocol requests. There's no
reason that KDE or GNOME control-panel type applets can't
achieve the same thing.
4) People won't understand that the purpose of the package is
just to bootstrap an X session -- without using a display
manager -- which might actually run on a remote host. While
the programs in xinit will be X clients in the strictest
sense (because they use the X protocol to communicate with an
X server), they aren't user-interactive GUI apps. Sure, the
purpose of the package is easily documented in the package
description and elsewhere, but if you think people will read
this, you've forgotten Rule #1 of Debian: armchair package
maintainers never read things like package descriptions when
telling another package maintainer how to organize his
packages. (Hello, Nick Phillips.)
I have no intention of splitting xbase-clients into xbase-clients-core,
xbase-clients-dps, and xbase-clients-gl, or what have you. Extensions
like Xrender, DPS, and GLX are increasingly important in XFree86, and it
doesn't make sense to me to hide these things from the user. I will
continue to close bugs asking for such packages, because I think what
most of these people are really after is the new "xinit" package anyway.
At present, I am leaning in favor of implementing this proposal.
However, I could be dissuaded.
I am seeking feedback on this proposal. I am NOT currently seeking
feedback on auxiliary matters.
Specifically:
1) This is NOT a proposal on what the metapackages should depend on; and
2) This is NOT a proposal on whether or how xbase-clients should be
further fragmented.
Both of these are issues to be decided *after* this one.
Please address only the core of the proposal, which is:
To create a new package "xinit" containing the programs xauth, xinit,
and startx, and their manual pages.
Comments?
[Remember, please followup to <debian-x@lists.debian.org>.]
--
G. Branden Robinson | You can have my PGP passphrase when
Debian GNU/Linux | you pry it from my cold, dead
[EMAIL PROTECTED] | brain.
http://people.debian.org/~branden/ | -- Adam Thornton
pgp1RNM01b0lg.pgp
Description: PGP signature
