In the case of existing g-prefixed utils, I think it would make sense to
have the "non-prefixed" version in /usr/gnu. The g-prefix isn't
compatible with many configure scripts and it ends up that quite often
the GNU equivalent simply isn't found. If the /usr/gnu could be added to
the front of a user's path (if they desire of course) then such scripts
can be used without complexity.
To implement this I would propose that the /usr/bin/gXXXX be a hard-link
to /usr/gnu/bin/XXXX
So what happens to the existing /usr/sfw tools that conflict here - can
it be presumed that they will be decomissioned in preference for the
/usr/gnu equivalent? Just seems to make sense to me...
Darren.
Stephen Hahn wrote:
> 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.
>
