* Danek Duvall <danek.duvall at sun.com> [2006-05-01 11:45]: > On Mon, May 01, 2006 at 11:15:34AM -0700, Stephen Hahn wrote: > > > | 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. > > It might be useful to say that projects may choose to make GNU extensions > available in the /usr/bin variant, if architecturally acceptable? Will change.
> > | 2.4. 'g' Prefixing > > > > | 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. > > I'm not sure how much PSARC currently looks out for this, but should it > warn project teams adding a new (non-GNU) command to /usr/bin that a > potential conflict might occur should another project choose to integrate > the GNU command? Or should the answer always be that any GNU command > coming in after a non-GNU command of the same name receive a g-prefix? I think that an ARC should ask if the project team has verified that the component names have no known conflicts. > > | 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.) > > Is 1G a typo here, given the use of "GNU" elsewhere? Typo; will fix. > > 3. Interfaces > > > > /usr/gnu Directory hierarchy Stable > > /bin > > /sbin > > /lib > > /info > > /etc > > /usr/gnu/etc should almost certainly be /etc/gnu instead -- or a symlink to > it -- in case /usr is a read-only filesystem. Okay. > One thing I think this case is missing is a suitable definition of GNU. Is > it specifically a label for the software coming from the FSF? Or something > endorsed by the FSF as part of the GNU project? Or generically some > utility that you might expect to find on Linux, but not (yet) Solaris? I answered this in my response to Peter: this really is about the replacement Unix environment provided by GNU. Non-conflicting objects always go in /usr/bin. > One example comes up when looking for naming conflicts between /usr/sfw/bin > and /usr/bin. The only existing conflict (on snv_36) is "profiles". The > two versions are used for completely different things -- the one in > /usr/bin is related to RBAC, and the one in /usr/sfw/bin is related to > samba. Question is -- is samba sufficiently "GNU" for the purposes of this > case? Should all of samba be left behind in /usr/sfw? Should only > profiles be left behind? Should it be moved to /usr/gnu/bin? Should it be > moved to /usr/bin and renamed to something unconflicting? Or should we > have a completely new hierarchy? (I'm not sure I like any of those > answers, FWIW.) Samba is not part of GNU. What we end up talking about is how to resolve name conflicts between two command sets with long histories. I would argue that we have to make a more generic statement about either prefixing (your unconflicting choice) or alternate hierarchies. (Common use versus default paths.) That's not this case, but we will need to revisit to make SFW work consistently. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
