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. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnsqguto.GNUs_not_UNIX!%ya...@gnu.org
