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@xxxxxxxxx]
Received: Thursday, 20 Jun 2013, 7:53
To: devel@xxxxxxxxxxxxxxxxxxxxxxx
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
