Suggested packaging guideline: avoid running autoreconf

Adam Jackson ajax at redhat.com
Mon Oct 13 13:16:43 UTC 2008


On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> When the estimate of "300 broken packages" was tossed out in the libtool
> 2.2.x thread, I figured there was no way *that* many packages could be
> running autoreconf or libtoolize.  But I have been surprised to find no
> advice against this practice in Fedora's packaging guidelines; and in
> light of that, the number is not quite so incredible.
> 
> While forbidding the use of autoreconf (or similar: autoconf, automake,
> libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> appropriate for the packaging guidelines to point out the pitfalls of
> this practice and advise packagers to avoid it where possible.
> 
> So what are those pitfalls? By running autoreconf, the RPM build becomes
> exposed to different versions of autoconf, automake, and libtool than
> were used by the upstream developer to create the upstream source
> package.  Newer versions of these tools have the potential to introduce
> incompatibilities, breaking the RPM build.  Rather than patching
> configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> the configure script and Makefile.in files.

No thanks.  Patching Makefile.am at least stands a chance of applying
correctly across multiple releases of the package.  Worse, patching the
generated files stands a good chance of missing an instance of whatever
you were patching for when the next release comes out.

Packages change version much more often than libtool changes version.
I'd rather go with the method that's resilient against the more common
change.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081013/62c98e70/attachment.sig>


More information about the fedora-devel-list mailing list