On Friday 28 April 2006 04:56 pm, Stephen Hahn wrote:
> 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
Not sure my vote/opinion matters, but +1.
ajd
>
> ----
>
> 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.
