[companion-discuss] Re: [tools-discuss] Proposing /usr/gnu, 4

[Bart Smaalders]

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