I hate to ask, having just spent nearly 10 years trying to get X moved
from /usr/openwin to /usr/X11, and finally being almost finished with
that, but is it time to stop segregating X11 and move to /usr?

We've had links from /usr/lib to /usr/X11/lib for the libraries since
Solaris 2.6, so they'd be in the default path and not require -L or -R
at build time, for easier compiling, so that would just replace the
links with the real libraries.

The programs and man pages would move into the same directories as gnome
and the rest of the system, instead of being off in their own world, and
one of the last parts of the system left in a separate subhierarchy of the
filesystem.

Having a separate /usr/X11R5 or /usr/X11R6 made more sense in the days
when those were built and installed from a single source tree, so if you
wanted a different version or a customized version, you built the entire
window system and replaced the entire directory.   And when we shipped
SPARCstation 1's with 105Mb hard disks, being able to put /usr/openwin
on a separate partition (local or remote) was crucial.

But today, it just makes X different and harder to find and use.
Since the LSB/FHS only allowed /usr/X11R6 as an exception to their
"everything under /usr, not /usr/foo" rule, when the Linux distros
moved to X11R7, they moved X into /usr/bin, /usr/lib, etc.   Since
X11R7 was also the release in which we split the X source tree from
one monolithic build into individual releases/builds of each library,
program, driver, font set, or other module, that wasn't a problem for
customizers, since they'd only be replacing xterm or their video driver
some other program or library, not the entire window system.

If we're going to do this, the ideal time to do so is in the next 6 months,
so it's baked in before Solaris.Next, which is already a Major release in our
compatibility taxonomy due to the change of default filesystem (zfs) and
packaging system (IPS) - we might even be able to do it as part of transitioning
our builds to generate IPS packages, since we'll be creating new package
manifests for those, and could just create them from the start to deliver
to /usr/bin, /usr/lib, etal.

Is there any strong reason we should be considering against doing this?

-- 
        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering


Reply via email to