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