On Sun, Dec 20, 2020 at 11:54 AM Ross Burton <ross@xxxxxxxxxxxxx> wrote: > On Sun, 20 Dec 2020 at 16:46, Bruno Haible <bruno@xxxxxxxxx> 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
