Re: Conflict/dependency granularity

[Richard Kettlewell <richard@elmail.co.uk>]

Bill Mitchell writes:
>>> In this particular example, the ls program could no doubt go
>>> in /usr/local/bin just as well (though there might be a config
>>> file which needs to go in /etc), but there are probably other
>>> examples which need to go into /usr/bin.  A cooperating
>>> system of programs, possibly, which have it hardcoded
>>> to look for one another in /usr/bin.
>> 
>> But such a system would have problems under any other operating system
>> and should still be fixed.  There's only so far one can go in terms of
>> working around other people's bugs.
>
>Where's the bug here?  And by whose standards is it a bug?
>(I should check the FSSTND before I ask that question, to see if
> it reserves /bin, /usr/bin, and so forth for the distribution
> provider, but my copy is at home.  I don't think it does)

I was under the impression that /usr/local was the right place - as
opposed to /bin and /usr/bin - for software not supplied by the
distributor in virtually every variant of Unix under the sun.

We don't expect to support people who try to encroach on the C
library's namespace - if you redefine printf you get what you
deserve.

The FSSTND says, among other things:

  Locally installed software should be placed within /usr/local rather
  than /usr unless it is being installed to replace or upgrade
  software in /usr.

In the case of Debian, if part of some package is worth upgrading or
replacing then there should be a .deb file to do it; so there is no
call for local administrators to install things outside /usr/local
(from a FSSTND POV).

ttfn/rjk