[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 branden@debian.org | brain. http://people.debian.org/~branden/ | -- Adam Thornton
Attachment:
pgphIYZexPsxW.pgp
Description: PGP signature