Disable xterm and XRX builds per default / [Fwd: CVS Update: xc (branch: trunk)]

Keith Packard keithp at keithp.com
Mon Jan 24 09:48:10 PST 2005


Around 11 o'clock on Jan 24, Egbert Eich wrote:

> The usual way to do it would be to say "we don't know if anybody still uses
> it, some people believe it should be deprecated therefore lets disable it
> and see who complains" - that's been the procedure with PEX and XIE.
> In the vast majority of cases there is no need to go thru any board.

The usual way should involve reasonable discussion; at this point we have
no discussion at all.  Let's try to insert some reason into this process.  
I know I'm not usually reasonable, but I'm going to try and pretend for a 
few minutes.

There is significant precedent for no longer building xterm by default on
linux platforms.  There are many packages which X.org includes in the
distribution but which are maintained and distributed by other people --
expat, FreeType, fontconfig to name a few.  These used to be built within
the X.org tree on all systems, and now most config files default to using
the system provided ones.  I don't recall any X.org Board involvement in
the decision to change this for a a particular platform.

Xterm is a particularly egregious case here -- while the other external 
packages are included because X.org packages depend on them, Xterm is 
included purely because it used to be maintained by X consortium staff.  
It has not been maintained by anyone within the XFree86 or X.org trees for 
many years.

Disabling it by default is almost entirely beneficial as now most users
won't have their vendor's version of this package overwritten by whatever
X.org decided to include in their release, or whatever the user has
downloaded from upstream.  I would further support the removal of xterm
from X.org CVS and its replacement with a note pointing at the upstream
maintainer.

Xrx is a different matter -- X.org is the canonical upstream source for 
this software and not building it by default means that you can't simply 
build X.org bits and replace everything for which X.org is the supplier.

A simple policy that X.org builds and installs by default only that
software for which it is the canonical source seems very reasonable and can
be applied dispassionately in these cases.  We should discuss whether we
should include known-compatible versions of some less common external
packages in the future, but I strongly disagree that any of this should be
built by default.  A default build should replace precise that software 
which X.org is responsible for.

> I personally would prefer to have a per-distributor configuration 
> file which can easily be included when a certain distro is detected.

I would not like to see this automatically done though; X.org should build
precisely the same on every platform.  The existing distribution detection
mechanism has confused me several times, making it very difficult to
predict what will be built on any particular platform.  Is there precedent 
in other well maintained packages for this kind of automatic customization?

What I would like to encourage is for some of the public distributions
(like the BSDs, Debian, Gentoo, Fedora, etc) to use X.org CVS to maintain
their build mechansism for the X.org related packages.  I think that would 
improve the quality of those packages while making it clear what parts of 
the build are 'standard' X.org and what parts are 'added value'.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050124/e5bcfd5b/attachment.pgp>


More information about the xorg mailing list