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
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
tools-discuss mailing list
[email protected]
