On Sun, Dec 20, 2020 at 11:54 AM Ross Burton <r...@burtonini.com> wrote: > On Sun, 20 Dec 2020 at 16:46, Bruno Haible <br...@clisp.org> wrote: >> This patch is already in Gnulib since 2020-12-09. But when people >> run 'autoreconf' on an existing released tarball, they are effectively >> combining an older Gnulib with a newest Autoconf. >> >> Why do people do that? The point of tarballs is that you can run >> './configure' right away. >> >> If people want to modify the build infrastructure, it would often be >> more reasonable to start off the git repository of the package (possibly >> from a specific release tag or release branch). > > Because it’s not uncommon to need newer config.status, or updated m4 files, > or to patch Makefile.am or configure.ac.
Also, in my experience downstream redistributors prefer to work from tarballs, for several different reasons: tarballs tend to come with more provenance information (e.g. PGP signatures); working from a git checkout may require any number of unusual tools that aren't required for tarball releases; figuring out exactly which git commit corresponds to a tarball is often more difficult than it ought to be; and so on. I'm not happy about needing to kludge backward compatibility with the older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it. zw
