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