Re: Conflict/dependency granularity
Bill Mitchell:
The illustration which comes immediately to mind probably isn't a
good one. The spiffy color ls program provided with SlackWare
(which I personally don't like and would rather not install) really
grabs lots of people. Not available on your debian system? No
problem. Just let me mcopy it off to flopy disk for you, and you
can put it in /usr/bin.
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.
One big problem with color ls is that it inserts strange characters
into the output stream that could confuse various programs. [I dunno
off hand -- emacs dired might cope or might not, but how about systems
using expect or pty?]
Given that constraint, I don't think it's a good idea to overload the
name 'ls' for this purpose. Some other name (e.g. 'dir') would
probably be more appropriate. In particular, I think it would be very
confusing to novice users (the people we're supposedly trying to help
here) if the behavior of ls was affected by whether /usr/bin appears
before /bin in $PATH.
However, perhaps someone was repairing a debian system, and the only
ls they had handy was this color ls. In that case, it would be
perfectly appropriate to put it in /bin. In this case, it's perfectly
reasonable for dpkg to upgrade ls if someone re-installs fileutils.
If it were my system, I'd be pretty upset if I had trouble
re-installing fileutils in such a circumstance.
--
Raul
Reply to: