Bug#53759: revision of the "to build with X support or not" policy
Branden Robinson <branden@ecn.purdue.edu> writes:
> 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.
I think I agree with the second poster. The new policy wouldn't really specify
anything. I think we should strongly favour no package splits unless there's a
major difference in functionality, either in features or in stability or
something.
Also, there are two different kinds of splits going on these days, one of
which is much less annoying than the other. Some packages have -x11 [*] or -x
packages that merely separate the parts of the system that depend on x into a
separate package. These don't impose added complexity on the packager, and
don't force the administrator to make an extra choice between two similar
packages. So they don't suffer from the problems -nox and -x packages have.
[*] I disagree with Branden about -x11 being bad. I agree there won't be an
x12 any time soon and x10 is obsolete, but -x could be any number of things
(extensions, external, etc), whereas -x11 is unambiguous and clear.
> 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.
They only need xlib6g. You don't need any support files or the server or
anything else. There no obvious need to not have one extra library installed
or any reason these machines are excluded from having something like Emacs
installed.
I had a project in mind at one point to do an automatic null library generator
that would give us a fake xlib library to link against if xlib wasn't actually
present. I don't think it would actually be hard, iterate through the symbols
in xlib and make aliases by each name to a function that just returns 0. This
would also solve the svgalib problem without a specialized package. And
probably others as well.
--
greg
Reply to: