Stefan Teleman writes:
> The other problem with having symlinks in /usr/bin is that we implicitly
> assert
> a preference for one version of binutils, or GCC, over another.
That's not a problem, that's a benefit.
Those who want a particular version (and no other) can either
include/exclude specific packages to get to that state or grovel about
in /usr/gnu/gcc-mumble/frotz to get the desired bits.
Having a canonical version in /usr/bin is a *good* thing, as it makes
our system much more like others, where you don't have to putz around
with $PATH in order to get common packages to build.
> the symlinks in /usr/bin point to the sole instance. This no longer holds
> when
> there is more than one version of either component available: we are making
> an
> implicit value judgement ("the latest version is the one we like best"). This
> can create binary compatibility problems.
I think the alternative is far worse.
Those who don't care what version they get can look in /usr/bin, and
we'll give them the benefit of the freshest bits there. Those who do
-- for whatever reason -- care can specify exactly what they want.
I don't see how it really could be otherwise. It'd be just silly to
make /usr/bin be the oldest bits, and it'd be really confusing and
weird to make /usr/bin appear to have different contents for different
users.
> > In other words, /usr/bin/gar makes sense, as does /usr/gnu/bin/ar, but
> > /usr/gnu/bin/gar doesn't make sense.
>
> I can then change the bits in /usr/gnu/bin to remove the 'g', with the
> exception
> of gprof.
Bottom line: you're delivering something in /usr/gnu/bin and /usr/bin
that has the same name, then that's a mistake. /usr/gnu/bin is
supposed to shadow /usr/bin, not contain a replica.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
