[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#4057: compress package install additional zcat



> 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



Reply to: