Stephen Hahn wrote: > Traditionally, the commands environments are incomplete: they do > not provide entries for each and every command available in > | /usr/bin. In the past, the environments have also been proper > | subsets of the system default commands: there are no commands that > | are not also present in the system's default command environment. > | Because there are numerous commands associated with the GNU > | environment that are not available in a default environment, this > | case proposes that a path setting of > | > | PATH=/usr/bin:...:/usr/gnu/bin > | > | allows access to the GNU commands with no equivalent in the default > | environment, while a path omitting /usr/gnu/bin would exclude these > | commands. This policy is in conflict with the general thesis of > | PSARC/2005/185, but no economical alternative appears to exist.
Economical in what terms? This seems to have been prompted by Rainer's comment: > I think this needs clarification: consider a GNU package like coreutils > which has both components which conflict with their /usr/bin counterparts > (like ls) and those that don't exist in /usr/bin (or anywhere else, like > seq) and thus don't conflict. I cannot believe that the proposal is to > introduce the non-conflicting tools into /usr/bin, and leave the rest of > the package in /usr/gnu/bin. Apart from being a maintenance nightmare (the > GNU packages just don't provide the infrastructure to install different > binaries into different bindirs), it takes away the possiblity to run in a > pure Solaris (i.e. non-GNU) environment (where seq doesn't exist). > Why is this desirable? Solaris /usr/bin is already an amalgam of BSD, SVR*, xpg*, gnu and various other bits and pieces. I guess my view is that Solaris is a lot like English; it borrows (and bastardizes, sigh) words from many languages as long as they're unique, and no special effort need to be made to avoid words of foreign provenance*. > My suggestion is to keep any GNU package with any conflicting commands in > /usr/gnu completely, and only introduce those with no conflicts (like CVS > or RCS) into /usr/bin, if at all. I'm not yet sure about the criteria > (apart from no conflicting components) to install a GNU package into > /usr/bin directly. The practical difficulties involved in creating svr4 packages that install into both /usr/bin and /usr/gnu/bin in the SFW consolidation doesn't seem that large, in terms of how we build the SFW consolidation. Right now we often make in the source tree and then run a per-pkg script that does the install into the proto area. We're going to do some special futzing anyway to create the symbolic links for all the g* cmds, anyway. There is some cost here, admittedly, but a "maintenance nightmare" is a bit strong. - Bart *dictionary.com: [French, from provenant, present participle of provenir, to originate, from Old French, from Latin prvenre : pr-, forth; see pro-1 + venre, to come; see gw- in Indo-European Roots.] -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
