Re: Color-ls package

[Shawn Asmussen <shawn@nfinity.com>]

On Fri, 15 Mar 1996, Syrus Nemat-Nasser wrote:

> On Sat, 16 Mar 1996, Ian Jackson wrote:
> > I think that, given how badly designed colour-ls is, it should be done
> > in a separate package and should not replace the standard /bin/ls even
> > if you install it.  After all, given that dircolors is spouting stuff
> > to make aliases anyway it might as well include a path to the modifies
> > ls.
> 
> Fine. So I make a package which includes ls and dircolors in /usr/local/bin.
> It also adds the dircolors manpage and places a (renamed) config file for
> dircolors in /usr/local/etc.  This is fine if people want to have extra
> binaries rather than alternate binaries.  
> 
> > You should certainly not release modified versions of other packages
> > and change only the version number; especially with fileutils (an
> > Essential package)
> 

I definately do not like the idea of putting an alternate ls in 
/usr/local/bin. As I see it (and currently have it installed),  it should 
replace the standard ls, either by being in a package that overwrites the 
current ls binaries or by getting with the guy who mainains the fileutils 
package and have him replace ls with the colorized ls (What is this about 
color ls having problems, I wasn't aware of anything wrong with it. I 
thought it was just gnu ls patched to provide color output.) I wouldn't 
mind just seeing it become the standard debian ls. As far as I know it 
will behave just like regular ls if you configure it so that it doesn't 
use color.

I think maybe this issue raises a more general question. How should 
packages that provide alternatives to programs that are subsets of a 
larger package be handled? How does the current color xterm handle that? 
Does it replace the old xterm, or is it added as another alternitive 
xterm on the system?


						Shawn