Re: Autoreconfing guide
Russ Allbery wrote:
> I would still use dh-autoreconf. It's not as critical, since it's
> unlikely to be necessary for supporting new architectures, but I
> think the Autoconf and Automake files are better treated as source,
> and the generated files regenerated on every build.
However, this is not how the GNU build system is intended to be used.
> This ensures that the files can still be generated from the source,
> which in turn ensures that anyone wanting to make changes to the
> source package will be able to do so easily.
This is an obvious plus, but consider the cons:
- It can provide non-deterministic builds for packages which misuse
the build system (improper quotation, usage of broken third-party
macros, etc).
- It can provide non-deterministic builds for legitimate use, when a
macro changes its semantics (this used to happen quite a lot in the
past).
- It can introduce bugs for no good reason if a buggy
Autoconf/Automake version is used (either an upstream release that
introduced a regression or caused by a Debian patch).
- Packages may (will?) FTBFS if they're silently "upgraded" to a new
Autoconf/Automake release that requires sourceful changes to
configure.ac/Makefile.am's/etc and such changes are not made by the
upstream/Debian maintainer (consider binNMUs, or the regular archive
rebuilds).
- All of the above can happen on a large scale if a big library
transition is involved and some stack of packages is being rebuilt.
Reply to: