[desktop-discuss] Proposing /usr/gnu

[John Rice]

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 (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.
>
>  
>