Michael Meskes writes: > Package: compress-package > Version: 1.2-1 > > Compiling and installing the compress source found on ftp.inria.fr I get a > file /usr/bin/zcat. However, gzip already install zcat in /bin. I cannot see > how it's useful to have both. :-)
Hmmm. This is somewhat more complex than it looks like. I cannot just remove /usr/bin/zcat because it is intimately linked with compress. If you say 'man compress' for example you'll get the synopsis for zcat too and if the corresponding zcat would not be provided then I think users can be confused. In addition I have no control about what programs will be built by make-cpkg. A gzip program could even be generated (now that I think of it, this is something I could check for!). What I want to say is that it is really difficult to filter things in the generated package because of documentation, related files etc. My opinion is that gzip should *not* provide /bin/zcat but rather /bin/gzcat (and the same for other z* tools). The /bin/zcat program is just *not* zcat, it also handles gzip files which the original zcat program cannot do. I think that we should have /bin/gzcat (or even /usr/bin/gzcat because gzip only should be enough in /bin) and have /usr/bin/zcat be a symbolic link to gzcat installed by the gzip package (and not an alternative as I suggested before). And most importantly people should refrain from using zcat in scripts when the intent is to gunzip something... If gzcat was provided and /usr/bin/zcat a symbolic link to it, the zcat link would correctly be diverted by any compress-package generated package and nobody would have two semantically different zcat commands installed by installing these packages. Yves.
