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. -- Braden McDaniel e-mail: <braden@xxxxxxxxxxxxx> <http://endoframe.com> Jabber: <braden@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
