> Hmmm. This is somewhat more complex than it looks like. I cannot just > remove /usr/bin/zcat because it is intimately linked with compress.
I disagree. The job of a package maintainer includes the process of doing things like this to a package. I have to do the same thing for the tar package, for example, where we've agreed that the tar package will not provide the 'rmt' executable, even though the GNU tar upstream sources makes it easy to include and annoying to remove. The complexity of handling alternatives just isn't worth it for silly stuff like this. > 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. By definition, a Debian system will have 'zcat' from the gzip package, since gzip is an essential base package. I don't see a problem here. > In addition I have no control about what programs will be built by > make-cpkg. Why not? I haven't looked at your compress package, but I can't see what the problem would be, offhand. > My opinion is that gzip should *not* provide /bin/zcat but rather > /bin/gzcat (and the same for other z* tools). I disagree. Prefixing stuff with the 'g' isn't particularly useful. In this case, the 'zcat' provided by gzip is a *superset* of the functionality provided by the 'zcat' in the compress package, and I can see no rational explaination for preferring the version that comes with compress over the version that comes with gzip. > people should refrain from using zcat in scripts when the > intent is to gunzip something... Why? > 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. Why don't you just make your compress package *not* provide the 'zcat' command, since any Debian system by definition has the gzip package installed (since it's an essential base package), and the 'zcat' provided with gzip is a superset that will always do the expected thing with a compressed file? I continue to be willing to convinced that I'm wrong about all this, but so far, all you've done is to say that "gzip's zcat does more than the one that compress provides", which I already knew... and then whine about how it's hard to make your package do what it should given what's already provided by gzip. Bdale
