Re: Color-ls package
> 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?
For a truly authoritiative answer, grab the xterm-color package and
*look* at it :-) As the package constructor, I can give you some
insight... xterm-color is intended to "upgrade" your xterm to a color
version. It uses dpkg-divert to shove the old xterm safely off into
xterm.mono, *not* so that people can run it (in fact, names with dots
in them used to completely trash the Xresources mechanism, though they
may have fixed that since X11R2 :-), but so that when you uninstall
xterm-color it can get it back.
I'd suggest that the color-ls be handled the same way (at one point I
was considering a "color toys" package that included color-xterm,
color-ls, setterm [except someone finally packaged it, not that it
works, since you still have to say TERM=console to make it *do*
anything] and anything else I could find [maybe a version of screen
which handles color? though supposedly the current one does, I can't
seem to convince it...] and that sort of thing. Other people seem to
have picked up the other pieces though; I'd be even happier if they
were default...)
Of course, ideally ncurses would have some new color functions, the
terminfo files would be upgraded (at minimum with a tag for "supports
ANSI color" like a PC with ANSI.SYS but an *additional* tag to
indicate that it *also* supports the linux hack additions that
setterm -store puts out, which unlike the color selectors don't come
from a standard, and don't really fit into the scheme very well...)
and then ls could deal a *lot* more cleanly...
Reply to: