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 <eggert@cs.ucla.edu> 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.