On Fri, Oct 24, 2008 at 12:01:52PM -0400, Stefan Teleman wrote:
> 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.
> Meaning: as long as there is only one version of binutils, or GCC,
> available, everything is fine: 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.
Lots of things in /bin are "versioned" in some way. That's not a good
reason to keep them out of /bin -- users still need them, and we're not
going to tell them to muck with PATH to get them.
We've been down this road and the ARC long ago decided to put all this
stuff in /bin, versioned or not.
You can always say that the link in /bin points to the latest version
and so is Volatile or Uncommitted, or you can say it's Committed and
commit to carrying that version as the default for a long time.
> [...]
>
> I can then change the bits in /usr/gnu/bin to remove the 'g', with the
> exception of gprof.
Aren't gas(1) and gld(1) normally invoked by those names on Linux
distros?
Nico
--
