Stephen Hahn wrote: >* Gary Winiger <gww at eng.sun.com> [2007-01-23 22:07]: > >>>Standards, Environments, and Macros gnu(5) >>> >> Nit. I presume filesystem(5) will be ammended as well ;-) >> But, if not, why not. >> > > It's an omission. I would propose adding something like > >+ /usr/gnu >+ >+ GNU commands environment: executables, documentation, and >+ supporting files. >
Just a nit, but with that wording, I'd be very confused to see bash (and others) in /usr/bin. /usr/sfw was fairly straightforward - where we installed software that was bundled but not part of ON. This was problematic for many because the default paths of various environments do not include /usr/sfw. In the submission, you write: > An application that wants to use GNU utility variants in preference > to all other utility variants on the system must set the > PATH (sh(1), ksh(1), bash(1), etc.) or path (csh(1), etc.) > environment variable as follows: Is there a variant of bash that _isn't_ the GNU one? The goal of creating /usr/gnu for commands that have conflicting behaviour with tools we provide (make being an obvious example) is good but it needs to be made more clear that /usr/gnu is for exceptions that conflict with Solaris, as you state here: > Similar to the XPG4 and XPG6 environments, if the behaviour of a > GNU command conflicts with the historical utility's behaviour, the > historical utility remains in /usr/bin; the GNU variant is provided > in /usr/gnu/bin. (In special cases, a copy of the variant, > prefixed with the 'g' character, may also be present in /usr/bin. > For example, /usr/gnu/bin/install is also provided as > /usr/bin/ginstall.) In cases where no historical equivalent was > previously provided, the GNU command will be present in both > /usr/bin and /usr/gnu/bin. The decision on whether to prefix a binary's name with 'g' should take into account whether or not it is already present in any of the directories we provide binaries in (/usr/bin, /usr/ccs/bin, /usr/sbin, others?), not just /usr/bin. I would be tempted to say that the architecture for /usr/gnu should be that unless Sun provides a command with a similar name, programs should always be installed into /usr/bin, not /usr/gnu/bin, except in the case of those with a 'g' prefix - 'g' version in /usr/bin, non-'g' version in /usr/gnu/bin. This way people aren't required to modify their default environment in order to access the extra tools available. Otherwise we're just reinventing the /usr/sfw/bin problem but with a new name. In addition, if we are going to provide /usr/gnu (for the purpose as stated) then we need to have a simple way to "use" it. Something along the lines of a radio button on a login screen or when doing an install or creating a user that says "GNU command line environment" or similar. That's likely to be beyond the scope of this case but without it, for "too many people", /usr/gnu will be just another /usr/sfw, different only in name. I'd also like to see some thought given to libraries - is there any intention to create a /usr/gnu/lib, how is that inteded to be used vs /usr/lib and /lib, etc, discuss shared library names and their conflicts, do people need to use LD_LIBRARY_PATH in addition to changing PATH, would /usr/gnu/bin/make pull in as/ld from /usr/gnu too, link against glibc, etc... Darren
