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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
