> 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...
