Subject: Bug#4057: compress package install additional zcat

From: Michael Meskes <[email-masked]>
Date: Tue, 6 Aug 1996 11:01:31 +0200 (MET DST)

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

Michael
-- 
Michael Meskes                   |    _____ ________ __  ____
[email-masked] |   / ___// ____/ // / / __ \___  __________
[email-masked]                  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[email-masked]                |  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!                | /____/_/      /_/  /____/\___/_/  /____/

---

From: Yves Arrouye <[email-masked]>
Date: Tue, 6 Aug 1996 23:11:59 +0200

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

---

From: Bdale Garbee <[email-masked]>
Date: Wed, 07 Aug 1996 00:17:46 -0600

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

> too and if the corresponding zcat would not be provided then I think

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.

> make-cpkg.

Why not?  I haven't looked at your compress package, but I can't see what the
problem would be, offhand.

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

Why?

> 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

---

From: Michael Meskes <[email-masked]>
Date: Wed, 7 Aug 1996 12:01:12 +0200 (MET DST)

> too and if the corresponding zcat would not be provided then I think

I've found nothing in your zcat that GNU zcat can't do.

> zcat program cannot do. I think that we should have /bin/gzcat (or

But that means it can do more than the original one. So why not using this
name?

Michael

---

From: Richard Kettlewell <[email-masked]>
Date: Wed, 7 Aug 96 11:05:40 +0100 (BST)

Yves Arrouye writes:
> > 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. :-)
>

IMHO:

There should be one zcat and it should always be gzip.  This won't
break anything as gzip understands .Z files...

Making zcat point to compress even sometimes will definitely break
things; IME much of the Linux world has been assuming it's gzip for a
number of years.  That seems unlikely to change.

compress is obsolete software; there's never any need to use it to
uncompress things.  Indeed, my experience (err, on Sunos rather than
Linux, so this may not be relevant) is that gzip is much more reliable
even at uncompressing .Z files.  I can't see the need to compress
things using compress either, as gzip produces smaller output, runs on
pretty much everything and is free.

-- 
Richard Kettlewell  [email-masked]  [email-masked]
                           http://www.elmail.co.uk/staff/richard/

---

From: Yves Arrouye <[email-masked]>
Date: Fri, 9 Aug 1996 01:11:00 +0200

> number of years.  That seems unlikely to change.

Ok, I've corrected that: I build a package without any of the commands
provided by gzip.

 > pretty much everything and is free.

Only one need: compress X font files, until someone makes the X font-reading
stuff aware of gzip.

YA.