Bug#4057: compress package install additional zcat
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. Ok, I've corrected that: I build a package without any of the commands provided by gzip. 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. Only one need: compress X font files, until someone makes the X font-reading stuff aware of gzip. YA.
Bug#4057: compress package install additional zcat
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.
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
Bug#4057: compress package install additional zcat
Yves Arrouye writes: 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. I've found nothing in your zcat that GNU zcat can't do. 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 But that means it can do more than the original one. So why not using this name? Michael -- Michael Meskes |_ __ [EMAIL PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
Bug#4057: compress package install additional zcat
Yves Arrouye writes: 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. :-) 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. 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 PROTECTED] [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/
Bug#4057: compress package install additional zcat
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 PROTECTED] | / ___// / // / / __ \___ __ [EMAIL PROTECTED] | \__ \/ /_ / // /_/ /_/ / _ \/ ___/ ___/ [EMAIL PROTECTED]| ___/ / __/ /__ __/\__, / __/ / (__ ) Use Debian Linux!| //_/ /_/ //\___/_/ //
