Here's an updated version based on feedback. Comments by end of
tomorrow, California time, please.
- 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.
2.1. Expected use
| Much like the use of the XPG4 [2] and XPG6 [3] 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 [4 - 5], 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 applicable to the /usr/gnu environment.
|
| 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 version should be
provided if already introduced. In cases where another operating
system has provided a 'g'-prefixed version, 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,
| 1G, 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.
| 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
/lib
/info
/etc
/usr/share/man/man1g
Manual page section Stable
4. References
| [1] B. Smaalders, PSARC/2005/185: Enabling serendipitous discovery,
| 2005.
|
| [2] J. Tornatore, PSARC/1994/161: XCU4 Conformance (XPG4
Commands/Utilities component), 1994.
| [3] J. Farley, PSARC/2003/418 SUSv3 Project Update, 2003.
[4] C. Fields, PSARC/2005/683: Add /usr/xpg4/bin/crontab and
/usr/xpg6/bin/crontab, 2005.
|
| [5] 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/
-------------- next part --------------
# HG changeset patch
# User sch at muskoka
# Node ID 350dc0eded3f9c46603b5f807311450023da1753
# Parent 32dfa3820183faf4c5122aeeb92b1f823c71ef32
update text for correct cases, manual page section, environment
completeness, serendipity
diff -r 32dfa3820183 -r 350dc0eded3f d-usr-gnu-fast-track.txt
--- a/d-usr-gnu-fast-track.txt Fri Apr 28 23:56:46 2006
+++ b/d-usr-gnu-fast-track.txt Mon May 1 18:09:35 2006
@@ -1,14 +1,14 @@
PSARC/2006/xxx
/usr/gnu
-Stephen Hahn (sch at sun.com) [and anyone else who dares to be forever
-blamed for this]
+Stephen Hahn (sch at sun.com) and Bart Smaalders (barts at eng.sun.com)
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.
+ 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.
@@ -17,63 +17,82 @@
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.
+ 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.
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
+ Much like the use of the XPG4 [2] and XPG6 [3] 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
- 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
+ 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. 'g' Prefixing
+2.3. Utility parity requirements
+
+ PSARC, in its opinion for PSARC/2005/683 [4 - 5], 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 applicable to the /usr/gnu environment.
+
+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 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.
+ introducing an otherwise name-conflicting GNU component may choose
+ to also provide one; otherwise, additional 'g'-prefixed components
+ in /usr/bin are discouraged.
-2.4. Manual pages
+ 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,
- 1G, to cover the introduced utilities. (Sections 1MG, 3LIBG, and so
- forth can be added as necessary.)
+ 1G, 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,1g,1
+ MANPATH=/usr/man,1gnu,1
to prefer the GNU project environment reference manual, and
- MANPATH=/usr/man,1,1g
+ MANPATH=/usr/man,1,1gnu
to use the GNU environment manual as a fallback.
-2.5. Future possibilities
+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.
+ one or more mechanisms. This change might also involve the
+ provision of complete commands environments, as mentioned in Section
+ 2.1.
3. Interfaces
@@ -89,12 +108,16 @@
4. References
-[1] J. Tornatore, PSARC/1994/161: XCU4 Conformance (XPG4
+[1] B. Smaalders, PSARC/2005/185: Enabling serendipitous discovery,
+ 2005.
+
+[2] 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.
+[3] J. Farley, PSARC/2003/418 SUSv3 Project Update, 2003.
[4] C. Fields, PSARC/2005/683: Add /usr/xpg4/bin/crontab and
/usr/xpg6/bin/crontab, 2005.
+
+[5] B. Sommerfeld et al, PSARC/2005/683 Opinion, 2005.
+
