On Sun, Jan 02, 2000 at 01:39:34PM -0500, Raul Miller wrote: > I'm not going to second this proposal. > > I think that it misses the real issue in favor of a rhetorical position. I disagree. The rationale for this proposal was twofold: 1) Several packages already flagrantly violate policy by shipping versions with and without X support; vim is one, gom is another. 2) Obviously there are systems out there that don't need a single bit of X support on them; at the same time, we don't want to categrically exclude certain popular tools from these systems. mtools and (again) vim are good examples. > I think that the real reason a package should be built without X support > has to do with the nature of that X support. If the support is buggy, or > loses functionality which would be available without that X support then > that's a good reason for providing a distinct version without X support. > > [In the case of vim, I seem to recall that syntax coloring didn't look > anywhere near as good with x support as in an "xterm-debian" terminal.] > > There's also the issue of expensive startup overhead in some marginal > X environments (for example: X over a modem link, or on an old '486), > but this strikes me as a local optimization issue. I offer the following > shell script to serve for those cases. > > #!/bin/sh > # given the full path to a debian program which > # offers X support, suppress that X support, > # unless the program is started with --with-x as the > # first argument. I disagree with this approach. It will waste even more space on average than the installation of an unwanted xlib6g package. I must oppose this amendment to my proposal. -- G. Branden Robinson | Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. branden@ecn.purdue.edu | Chemistry is really physics. roger.ecn.purdue.edu/~branden/ | Physics is really math.
Attachment:
pgpwtgBRzBazk.pgp
Description: PGP signature