I am sponsoring this fast-track for myself, with a timeout of Sept. 17,
and a release binding of patch (though delivery is only planned for
OpenSolaris & Solaris "Next" at this time).

This case is submitted to PSARC, as the traditional arbiter of the Solaris
filesystem layout, but cc'ed to LSARC, as it affects cases that LSARC reviews.

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


Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
         Obsolescence of /usr/X11
    1.2. Name of Document Author/Supplier:
         Author:  Alan Coopersmith
    1.3  Date of This Document:
        10 September, 2009
4. Technical Description

History:
--------

Historically Solaris delivered the X Window System software in the
/usr/openwin hierarchy, with subdirs mirroring /usr - /usr/openwin/lib,
/usr/openwin/bin, etc.

ASARC/1996/268 noted that the differing install locations made it hard
for users to compile software written for other platforms, so created
symlinks from /usr/lib to /usr/openwin/lib, and /usr/include/X11 to
/usr/openwin/include/X11, for the public libraries & headers.
(It notes "From the customers that I have dealt with, they feel like
*all* APIs belong in /usr/lib, /usr/include, and that Sun was just
annoying and foolish for being different." but it took many years
for Sun to take that advice to heart.)

PSARC 2004/187 established /usr/X11 as the hierarchy for the X Window
System software on Solaris, and began to phase out /usr/openwin.

PSARC 2008/405 case declared /usr/openwin as Obsolete and removed the
/usr/openwin hierarchy from the filesystem, leaving a symbolic
link to /usr/X11 in its place for backwards compatibility.

Numerous other ARC cases have established that /usr/bin & /usr/lib are
now the primary installation location for public binaries & libraries
on Solaris & OpenSolaris, and that subsystem-specific hierarchies are
now discouraged for commonly-used software.


Change:
-------

This case declares /usr/X11 as Obsolete and allows any files currently
delivered there to be delivered to the equivalent location under /usr.
Moves of individual files may be considered ARC Self-Review, with a patch
release binding, and not require ARC cases as long as they follow these
rules:

  - Symbolic links from the /usr/X11 locations to the /usr locations
    must be delivered for any public interfaces.

  - Delivery to the normal Solaris locations, following the guidelines
    of the "Recommended Installation Locations for Solaris-compatible
    Software Components" ARC Best Practice document and this case.

    Specifically, the major directory mappings will be:

    Previous location:                  New location:
     /usr/X11/bin                        /usr/bin
     /usr/X11/demo                       /usr/bin
     /usr/X11/include                    /usr/include
     /usr/X11/lib                        /usr/lib
     /usr/X11/lib/modules                /usr/lib/xorg/modules
     /usr/X11/lib/X11/app-defaults       /usr/share/X11/app-defaults
     /usr/X11/lib/X11/fonts              /usr/share/fonts
     /usr/X11/lib/X11/xkb                /usr/share/X11/xkb
     /usr/X11/lib/X11/xserver            /usr/lib/xorg
     /usr/X11/share                      /usr/share
     /usr/X11/share/man                  /usr/share/man

A future case may remove the /usr/X11 hierarchy completely, and leave
a single /usr/X11 -> /usr symlink, as 2008/405 did for /usr/openwin,
but there are many dependencies to resolve first.

The /etc/X11 directory is not affected by this case, and will remain as-is.


Rationale/Discussion:
---------------------

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
or some other program or library, not the entire window system.


6. Resources and Schedule
    6.4. Steering Committee requested information
        6.4.1. Consolidation C-team Name:
                X
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open


Reply via email to