[...]
> -1    This proposal puts a set of OSS utilities in
> /usr/bin where
> they become intermingled with core Solaris commands.
> .  It also
> puts conflicting commands in /usr/gnu. This lets the
> e user
>       choose between
>               Solaris versions 1st + Solaris-GNU versions 2nd
>               (PATH=/usr/bin:/usr/gnu)
>       and
>               Solaris-GNU versions 1st + Solaris versions 2nd
>               (PATH=/usr/gnu:/usr/bin)
> 
>       It does not allow for
> Solaris versions 1st + User-Provided-GNU versions
> ns 2nd
> That is, if I download/configure/make my own version
> n of the
> GNU utilities, I am faced with either using them to
> o the exclusion
> of any Solaris versions (PATH=/myGNU:/usr/bin) or
> r not using them
> at all.  There is no way for me to use the Solaris
> s versions 1st
>       and my GNU versions 2nd.
> 
> (I think a key aspect of this case is that it is
>  primarily focussed
> on managing conflicting binaries.  As a result,
>  the first example,
> PATH=/usr/bin:/usr/gnu/bin, isn't actually fully
>  simplified--it is
>    equivalent to PATH=/usr/bin.)
> I believe the issue raised concerns the provision
>  of a
> /usr/local/bin/foo, and selecting its preference
>  on a per-command
> basis against /usr/bin/foo and /usr/gnu/bin/foo.
>   It is true that
> the path mechanism in Unix always chooses the first
>  executable found
> in the list of paths given in the environment,
>  which leads to
> relatively crude outcomes when considering
>  individual commands
> implementations.  The proposal attempts to utilize
>  the solution in
> place for other command variant collections (UCB,
>  XPG4, XPG6).
> Remediation is available to local sites by
>  placing a preferred
> subset of commands and placing the path to that
>  subset ahead of the
> default entries, or via omission of the SFW
>  package(s) delivering
> conflicting functionality.  This omission may
>  cause other, dependent
>    packages to fail installation.
[...]

Why not avoid the problem by putting all the FSF stuff in /usr/gnu,
and having an optional package of symlinks in /usr/bin which no other
package with dependencies on the /usr/gnu stuff should require?  That way,
users could choose whether to have non-conflicting /usr/gnu commands added
to /usr/bin, or whether to leave them out; rather than building their
own directory of symlinks to non-GNU commands in /usr/bin and putting
that directory ahead of their directory of self-built GNU commands.
 
 
This message posted from opensolaris.org

Reply via email to