Indeed. This was a concern I raised when we first began the bootstrap. Blindly rerunning autoreconf in every case is a really bad idea. But doing it in a discretionary way, allowing the package maintainer to influence what happens (they in theory know whether this will work for their package and their upstream) is good.
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-----Original Message-----
From: Ben Boeckel [mathstuf@gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.
--Ben
Hm... it actually seems that there is a lot of common ground here,
and quite different from what a newbie will find if googling [1].
Yes, it's an old draft, but in a sense it't the most official
document found, I guess.