Since this topic arose during a discussion about developer readiness
of opensolaris, and got reasonably well characterized, and appears to
be gating on other improvements, I thought we should discuss further
with a draft in hand.
Comments welcomed.
- Stephen
----
PSARC/2006/xxx
/usr/gnu
Stephen Hahn (sch at sun.com) [and anyone else who dares to be forever
blamed for this]
1. Summary
A new directory hierarchy, to contain 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, as well as other
components, produced by the GNU project.
2.1. Expected use
Much like the use of the XPG4 [1] and XPG6 [2 - 4] environments, the
expected use of the /usr/gnu environment is to either prefer its
binary components to the system defaults, via a setting like
PATH=/usr/gnu/bin:...:/usr/bin
or to use these components as a fallback, if other environments do
not provide a component, with a setting like
PATH=/usr/bin:...:/usr/gnu/bin
2.2. Reliance on /usr/gnu/bin utilities
The individual utilities' stability levels dictate their
appropriateness for use by other components.
2.3. '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 version should be
provided if already introduced. In cases where another operating
system has provided a 'g'-prefixed version, the project team
introducing a GNU component may choose to also provide one;
otherwise, additional 'g'-prefixed components in /usr/bin are
discouraged.
2.4. Manual pages
In the interest of reducing manual page scavenger hunts, this
proposal recommends the introduction of a new manual page section,
1G, to cover the introduced utilities. (Sections 1MG, 3LIBG, 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,1g,1
to prefer the GNU project environment reference manual, and
MANPATH=/usr/man,1,1g
to use the GNU environment manual as a fallback.
2.5. 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.
3. Interfaces
/usr/gnu Directory hierarchy Stable
/bin
/sbin
/lib
/info
/etc
/usr/share/man/man1g
Manual page section Stable
4. References
[1] J. Tornatore, PSARC/1994/161: XCU4 Conformance (XPG4
Commands/Utilities component), 1994.
[2] C. Fields, PSARC/2004/431: Add /usr/xpg6/bin/ex, 2004.
[3] C. Fields, PSARC/2004/494: Add /usr/xpg6/bin/stty, 2004.
[4] C. Fields, PSARC/2005/683: Add /usr/xpg4/bin/crontab and
/usr/xpg6/bin/crontab, 2005.
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
