Once getting past the initial shock (okay, I've lived with /usr/X11 for a *really* long time now!), the case seems straight-forward and obvious. +1.
- Garrett Alan Coopersmith wrote: > 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 > > >