Subject: Re: bug#20104: [PATCH] gzip: make the GZIP env var obsolescent

From: Jim Meyering <[email-masked]>
Date: Wed, 18 Mar 2015 04:34:55 +0000

Glad you caught that.

That reminds me:  I added the following to the GNUmakefile
we find in projects like coreutils, grep, diff, etc. (it comes from
gnulib/top/GNUmakefile), and once/if GNU tar deprecates
that envvar, we'll have to adjust that, too:

  # Make tar archive easier to reproduce.
  export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner

The intent was to work (albeit degraded) even with non-GNU tar.
Now that I think about it, I dislike the idea of supporting inferior
tools when running commands to create a release tarball. That
process should be as repeatable as possible. Perhaps we should
try harder to find a tar-creating program that has options to do the
above, and simply abort when it is not found.

On Tue, Mar 17, 2015 at 11:20 AM Paul Eggert <[email-masked]> wrote:

> On 03/17/2015 07:53 AM, Jim Meyering wrote:
> > Very nice.
>
> Thanks for checking it.  I changed one minor nit (an if-then-else which
> was a tiny bit clearer with the if-condition negated and the then- and
> else- parts swapped) and installed the result.
>
> Hmm, after doing that, though, I discovered that Automake generates a
> dist-gzip rule that by default sets GZIP='--best' in the environment.  I
> think this is partly to work around the problem that GZIP in the
> environment can mess up how 'gzip' works, and partly to generate
> more-compressed output.  So this behavior by Automake is *both* a
> workaround for the longstanding gzip misfeature, *and* a use of the
> misfeature.  What a mess.
>
> I suppose we could fix Automake to supply --best in a more-portable
> way.  Or perhaps we could unbend a bit and allow GZIP to supply -1
> through -9, --fast, --best.
>
>