Bart Smaalders <bart.smaalders at Sun.COM> writes:
> 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:
At present, it is hard to discuss this outside of Sun since that PSARC case
isn't currently public.
> > 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*.
I think there are two arguments in favor of my approach to keep GNU
packages with conflicting parts completely below /usr/gnu:
* As we've observed a couple of times, several long-time/hardcore
OpenSolaris are purists who would like to stay away from the GNU command
set as far as possible. This may partially be just religion, but has a
foundation in ...
* ... the fact that often GNU maintainers care much less then they should
about backwards compatibility: observe e.g. the case of coreutils where
on one hand the maintainers regularly change output formats of commands
at their whim (ls is an example, since the exact format isn't prescribed
by POSIX.1), while on the other hand being anal-retentive about standards
compliance to the point where they remove support for legacy option even
in cases where POSIX.1 still allowed them (stuff like head -1 being
removed in favor head -n 1), which caused lots of uproar in other parts
of the GNU community (e.g. GCC where lots of scripts started breaking
unnecessarily on systems that happened to have recent coreutils
installed). It took quite some time and long and heated arguments to
have this at least partially resolved, so I can fully understand a desire
to stay away from such a moving target if possible. To put this in
perspective, I've historically provided the GNU commands for our users in
/vol/gnu/bin, which is prepended to PATH, to provide a common
cross-platform experience for Solaris, Tru64 UNIX, IRIX (and before that,
even AIX and NeXTstep). In recent years, I've become quite reluctant
to update those commands due to those incompatibilities.
> > 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.
Maybe, but in my opinion dealing with a whole GNU package in one consistent
way (i.e. completely in /usr/bin or /usr/gnu/bin) is more consistent with
user expectations than spreading it across different directories.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
