With various corrections and enhancements. More suggestions? (Take
your time; I'm learning Mailman's layout.)
- Stephen
----
PSARC/2006/xxx
/usr/gnu
Stephen Hahn (sch at sun.com) 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. The environments are also proper subsets: there are no
commands that are not also present in the system's default command
environment. 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 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. Manual pages
In the interest of reducing manual page scavenger hunts, this
proposal recommends the introduction of a new manual page section,
| to be represented in manual page text as "1GNU", to cover the
| introduced utilities. (Sections 1MGNU, 3GNU, and so forth can be
| added as necessary.)
Management of the manual path then proceeds along similar lines as
the executable path in Section 2.1:
MANPATH=/usr/man,1gnu,1
to prefer the GNU project environment reference manual, and
MANPATH=/usr/man,1,1gnu
| to use the GNU environment manual as a fallback (for searches of the
| entire manual page collection). If additional manual page sections
| are required, they should also be named with a "GNU" suffix and the
| section directory extended with a "gnu" suffix.
| In the standard configuration, the 1GNU section will follow the
| default 1 section in the default search order.
|
| 2.6. 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 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.
|
| 2.7. 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
| /lib
| /info
| /etc/gnu Directory hierarchy Stable
|
| /var/gnu Directory hierarchy Stable
|
| /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.
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
