Xorg version number change

[Daniel Stone]

On Mon, Oct 11, 2004 at 03:31:20AM +0200, Roland Mainz wrote:
> Daniel Stone wrote:
> > > > On Fri, Oct 08, 2004 at 04:52:22PM -0700, Keith Packard wrote:
> > > > > What 'the world' means is debatable, especially as many
> > > > > systems have a lot of paths with 'X11R6' encoded in them.
> > > >
> > > > Just because it's there and common practice, doesn't make it right. :)
> > >
> > > Yep. Long ago it was X11R5, before that X11R4. And switching the default
> > > dir to /usr/X11R7/ won't hurt neither less or more
> > > (backwards-compatibility can be guranteed via softlink from /usr/X11R6
> > > --> /usr/X11R7/ ...) ... :)
> > 
> > So we soft-link all the directories to each other.  That's so cool.
> > Very compelling argument for having them.
> 
> The link /usr/X11/ should link to the current version being in use. That
> allows an admin to have more than one tree and switch betweenm active
> version just via changing the soft link.

Is this the usual case?  Should we be designing the default case around
this?  I dare say no.

> > > BTW: Since a while Solaris has a link /usr/X/ which points to the
> > > currently installed version of X11... maybe the same should be done for
> > > the Xorg tree and then all version-independent paths should go through
> > > /usr/X/ (or /usr/X11/) instead of /usr/X11R(6|7)/ ...
> > 
> > Oh man, no.  Why?
> 
> Ask the original designers of the code... :)

That's not a valid reason -- if it can't be justified for any reasons
other than historic, then it can't be justified.  Of course, we have to
consider the weight of inertia wrt current behaviour, but since we're
changing anyway, we have to look at justifications for every option.
And so far I've only seen one justification for /usr/X11R7, and that's
not, IMO, a very good one (should we do $HOME/install/x, as I have on
some of my machines?).

> > For starters, I don't think this tree should even exist.  But if we take
> > it for granted that it must exist for some strange reason, why must we
> > include the version number in it?
> > 
> > GTK isn't installed to /usr/gtk+-2.4.
> > GNOME isn't installed to /usr/gnome2.8.
> 
> ... and GTK and Gnome are also known for other "good" design choices...
> =:-)
> Really... both _should_ live in /usr/gnome/ like all good Unix citizen.

We fundamentally disagree here.  I think the design choices made by GTK
in terms of how it installs and behaves wrt installation (pkg-config,
/usr, et al) are the best ones that anyone has yet made.

According to you, the only real 'good Unix citizen(s)' are things like
iPlanet, which still hang on to /usr/foo.

You should read what the Filesystem Heirachy Standard has to say on this
some day.

> > KDE isn't installed to /usr/kde3.3.
> 
> Happily lives under /opt/kde/ in SuSE and most other Linux versions (or
> /usr/kde/ on Solaris) ...

Does not do so under Debian or Red Hat.  I believe it does not do so
under Slackware or most other distributions, either.

> > xterm isn't installed to /usr/xterm-0.94.
> 
> BAD example as "xterm" is part of the X11 suite.

No, because it has a completely independent upstream (Thomas Dickey) who
distributes his own tarballs, and many people favour these tarballs over
the xterm included in the standard X11 distribution.

> > Apache isn't installed to /usr/apache-1.3.29.
> 
> It's /usr/apache/ here (Solaris) ...

This isn't the case as default in the build system, nor is it the case
on almost all other systems than Solaris.

> > To take the example of a proprietary UNIX suite par excellence; last
> > time I checked, iPlanet installed to /usr/netscape, not
> > /usr/netscape-iplanet-x.x.x.  So, even in the most abhorrent case of
> > there being a separate subdirectory under /usr (why? why? why?), there
> > is no way known the version number should be playing a part.
> > 
> > I don't think the separate directory under /usr should exist per
> > default,
> 
> So you want to stick everything into /usr/include/, /usr/lib/ etc.?
> Windows has such a "flat" filesystem layout where every application
> behaves like that. And from Windows also comes the term "DLL h*ll".
> Think about it...

That's like saying that both beer and water come in glasses, so water
must get you drunk.  DLL hell comes from many other problems, and
/usr/include and /usr/lib is not the issue.  Also, you can have paths
underneath /usr/include and /usr/lib, e.g. /usr/include/gtk+-2.0,
/usr/include/kde, /usr/lib/dbus-1, et al.

> > but if it does, there is absolutely no reason to include the
> > version number.  I think it's just dumb.  Really, really dumb.
> 
> It's not always dumb, sometimes it makes much sense (see the comment
> with the multiple versions above...).

Yes, that's all good, but how many people actually want to have multiple
versions of X installed?  Sure I do, and you might want to as well, but
I don't think most people care about it at all, to be honest.  They just
want to user their system, not be burdened by anachronistic crap like
this.

-- 
Daniel Stone                                            <daniel at freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20041010/aac3536b/attachment.pgp