This case went through a few minor revisions since it last circulated. Final comments prior to ARC submission are encouraged.
- Stephen [] See http://www.opensolaris.org/jive/thread.jspa?messageID=36453 for the previous version. ---- PSARC/2006/000 /usr/gnu Stephen Hahn (sch at sun.com), Rainer Orth (ro at techfak.uni-bielefeld.de), and Bart Smaalders (barts at eng.sun.com) ident "$Hg: d-usr-gnu-fast-track.txt c729279cb0f2 2006/12/13 15:27:06 -0800 $ SMI" 1. Summary A new directory hierarchy, to contain otherwise-name-conflicting GNU utilities under their original names, is proposed. A guideline for the provision of 'g'-prefixed variants in /usr/bin is also presented. This case seeks Minor release binding. 2. Discussion In an attempt to provide a more complete offering for software developers on OpenSolaris distributions (as well as more general goals of including useful software), this case proposes the introduction of /usr/gnu as a location for alternate implementations of standard tools produced by the GNU project. This case supplements PSARC/2005/185, "Enabling serendipitous discovery" [1]. The goals of the two cases are aligned; this case may propose refinements to the handling of specific scenarios. For the purposes of determining candidates for the GNU environment, the GNU packages of the FSF/UNESCO Free Software Directory are considered the authoritative list [2]. 2.1. Expected use Much like the use of the XPG4 [3] and XPG6 [4] environments, the expected use of the /usr/gnu environment is to prefer its binary components to the system defaults, via a setting like PATH=/usr/gnu/bin:...:/usr/bin Traditionally, the commands environments are incomplete: they do not provide entries for each and every command available in /usr/bin. In the past, the environments have also been proper subsets of the system default commands: there are no commands that are not also present in the system's default command environment. Because there are numerous commands associated with the GNU environment that are not available in a default environment, this case proposes that a path setting of PATH=/usr/bin:...:/usr/gnu/bin allows access to the GNU commands with no equivalent in the default environment, while a path omitting /usr/gnu/bin would exclude these commands. This policy is in conflict with the general thesis of PSARC/2005/185, but no economical alternative appears to exist. The manual page path will be managed similarly. (Use of the per-section ordering support man(1) allows in MANPATH was considered, but is not suitable for heterogeneous environments.) Although an environment could be modified to be a full alternative commands environment, that aspect is left to a future discussion. 2.2. Reliance on /usr/gnu/bin utilities The individual utilities' stability levels dictate their appropriateness for use by other components. 2.3. Utility parity requirements PSARC, in its opinion for PSARC/2005/683 [5 - 6], made policy a technical requirement that XPG4 and XPG6 extensions be also made available in the /usr/bin variant of the affected utility. This policy is not a requirement for the /usr/gnu environment; project teams may choose to enhance partially or completely the /usr/bin variant as part of providing a /usr/gnu utility. 2.4. 'g' Prefixing Historically, introduction of GNU utilities into /usr/bin has been done with a 'g' character prefixed to the utility name. This proposal amends this practice: the 'g'-prefixed variant should be provided if already introduced. In cases where another operating system has provided a 'g'-prefixed variant, the project team introducing an otherwise-name-conflicting GNU component may choose to also provide one; otherwise, additional 'g'-prefixed components in /usr/bin (or any other path) are discouraged. GNU components that do not conflict with existing or anticipated components in the system's default commands environment should not be placed in /usr/gnu, and do not require 'g'-prefixing. Both 'g'-prefixed and non-conflicting interfaces will provide access via /usr/share/man to their manual pages. (Such access may be implemented via symbolic links, for example.) 2.5. Other filesystem locations With the introduction of zones, customizable directories must be kept out of /usr to make sparse zones practical. This case reserves /etc/gnu and /var/gnu and their subdirectories as locations for customizable files required by the tools present in the environment, but does not mandate their introduction until an explicit consumer is proposed. Otherwise, and with the exception of the 'g'-prefixed components, the /usr/gnu hierarchy will be populated in accordance with the GNU coding standards [7]. (The specific exceptions are that the localstatedir and sharedstatedir settings will be "/var/gnu" and "/var/gnu/com", respectively, and the sysconfdir will be "/etc/gnu".) The most common directories are given in the Interface Table in Section 3. 2.6. Future possibilities One possible future direction is to extract the legacy tools from /usr/{bin,sbin} and provide them in a new, stable path like /usr/sunos/{bin,sbin}. The selection of the top-level /usr components can then be made a configurable aspect of the system, via one or more mechanisms. This change might also involve the provision of complete commands environments, as mentioned in Section 2.1. 3. Interfaces /usr/gnu Directory hierarchy Stable /bin /sbin /include /lib /libexec /share /share/info /share/man /etc/gnu Directory hierarchy Stable /var/gnu Directory hierarchy Stable /com 4. References [1] B. Smaalders, PSARC/2005/185: Enabling serendipitous discovery, 2005. [2] Free Software Foundation, FSF/UNESCO Free Software Directory, "All GNU Packages", 2006 (http://directory.fsf.org/GNU/). [3] J. Tornatore, PSARC/1994/161: XCU4 Conformance (XPG4 Commands/Utilities component), 1994. [4] J. Farley, PSARC/2003/418 SUSv3 Project Update, 2003. [5] C. Fields, PSARC/2005/683: Add /usr/xpg4/bin/crontab and /usr/xpg6/bin/crontab, 2005. [6] B. Sommerfeld et al, PSARC/2005/683 Opinion, 2005. [7] Free Software Foundation, GNU Coding Standards, 2006 (http://www.gnu.org/prep/standards/standards.html#Directory-Variables). -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
