Xorg version number change

Gene Heskett gene.heskett at verizon.net
Sun Oct 10 23:33:12 PDT 2004

On Monday 11 October 2004 01:13, Daniel Stone wrote:
>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 
>> > > > > 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.

If I can throw an oar in the water here Daniel, I'm rather enchanted 
by the softlink pointing to the version to run if more than one 
version is installed.  This will give us the ability to run the 
bleeding edge stuff, report any problems, change the link and go back 
to the old faithfull version all in about 10 minutes or less.

If this gets to be a habit, or is a problem for the gui's, let kde, 
gnome et all query the link somehow to see what version is present in 
case they want to throw more eye candy at the user of the latest 
version.  Each of them can then put in those few lines of code to set 
their environment vars and be ready for when you switch to a simple 
link of /usr/X11 in your next release.

In that event, it would be very nice if the logfile was named a bit 
differently between the versions, or included the version number, so 
that if an outright crash or ?? required a full reboot and restart to 
the old faithfull version before its functional enough to send an 
email, the logfile for the failed version was still available after 
the reboot.  Since your logfile isn't in the log rotation, I don't 
see that as a problem...

This makes sense to this old fart*, and would tend to encourage me to 
bleed a bit more profusely from time to time.  I've been known to do 
it before, but this would make the recovery a heck of a lot easier 
for a service thats so important to the day to day operations of the 
users desktop.  I have the disk space to play with, so thats not a 
problem.  Until I cleaned house in /root last week, I had 4 versions 
of kde installed, but mkde3.3 has been stable, so the rest got used 
for a game of space patrol.  But, this isn't exactly a sacrificial 
box, its my day to day box too, which makes easy recovery a 
desireable thing(tm). 

*Old fart: Officially turned 70 last monday...

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

More information about the xorg mailing list