rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

Alec Leamas leamas.alec at gmail.com
Thu Jun 20 13:50:12 UTC 2013


On 2013-06-20 14:19, Jonathan Masters wrote:
> 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 at gmail.com]
> Received: Thursday, 20 Jun 2013, 7:53
> To: devel at 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.

We have at least three cases?
- Ben's case: projects running auto(re)conf once, then committing and 
maintaining the generated files (and some years later, in desperation, 
goes for cmake...)
- Projects which intitially had a working autotools setup which have 
become more or less unusable in a modern environment.
- Projects which have a well maintained, working autotools setup - here 
it's natural to run autoreconf as part of the build.

Seems that we all agree that the last situation is the preferred one. In 
the other scenarios, it might make make sense to try to help upstream to 
update the obsolete configure.in/ac and Makefile.am. Or it just might 
not, and it's better to use the generated fiels.

This should really be a fpc ticket before we lose everything. However, 
my fpc quota has expired... ;)

--alec

[1] https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130620/3a9e903d/attachment.html>


More information about the devel mailing list