On Fri, Sep 11, 2009 at 12:55 AM, Alan Coopersmith <Alan.Coopersmith at sun.com> 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
Bold migration, Alan. Nice. I guess only the pkgdefs will be changed? Or are there plans to one day incorporate xwin into the OS/Net consolidation gate? Probably not. Too much speaks against this. But in theory it could be done. Based on what criteria have previous decisions (maybe of less scale) been made? By whom? %martin
