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

PROPOSED: new package: xinit

[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

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.

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.


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

Reply to: