Stephen - this looks great.
Definitely +1.
Apologies for not responding sooner, but having kicked things off with
the query on problems with building OSS on Solaris I headed off for a
long weekend (May Day bank holiday in Ireland, as all marathon runners
know) :) But laca as always covered all the bases, I owe him lots of beer.
So having:
All gnu tools moved into /usr where no naming conflict exists sounds
great. This coupled with Bartt's original proposal to move tools out of
/usr/sfw where no naming conflict/ compatibility issues, should really
help the cause of building OSS on Solaris. I assume this will cover
things like automake, autoconf and so on.
Reading all the post was a little confused as to why /usr/gnu as opposed
to /usr/oss ?But seems clear from the proposal that this is purely to
define the namespace clearly and not let it become another /usr/sfw
general oss bucket. So if we have other tools that do conflict with
what's in /usr and are not GNU, such as the Samba example Danek brought
up we'll just need to handle these on a case by case basis.
JR
P.s. The URL for the Original /. post is:
http://slashdot.org/comments.pl?sid=183611&cid=15166267
"- It takes me twice as long to build any OSS on Solaris - no one is
really developing on it consistently. Ever tried building Firefox on
Solaris?"
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
----
PSARC/2006/xxx
/usr/gnu
Stephen Hahn ([EMAIL PROTECTED]) [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.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
