Okay, this is my last major pass. First, I've added Rainer to catch
more of the blame. Second, the /usr/gnu hierarchy is consistent with
the expectations set in the GNU Coding Standards, except for the cases
that are associated with potentially per-zone state. Third, the
specific section invocation has been dropped, and the pages returned
to /usr/gnu/share/man.
Comments?
- Stephen
----
PSARC/2006/xxx
/usr/gnu
| Stephen Hahn (sch at sun.com), Rainer Orth (ro at techfak.uni-bielefeld.de),
| and Bart Smaalders (barts at eng.sun.com)
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 other goals),
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.
| 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
/usr/share/man/man1gnu
Manual page section Stable
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/
