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

[Jim Meyering]

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 <address@hidden> 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.
>
>