On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote: > 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. Patching Makefile.in stands a reasonable chance of that, too. Exactly what the odds are depends greatly on the nature of the change; and it is certainly the case that for a class of changes, the patch to Makefile.am is more likely to apply cleanly. Your implication that a patch to Makefile.in stands no chance of applying cleanly to future releases is simply hyperbole. > 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. I think the claim of such a "good chance" is, once again, hyperbole. Sure, there's *some* chance. And there's *some* chance of that regardless of what you file patch. Again, just what sort of increase to the likelihood of failure we're talking about depends greatly on the nature of the change. > 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. If you ran autoreconf, you also need to worry about upgrades to autoconf and automake in addition to libtool. Still, there are certainly packages that have more frequent releases than all three of those put together. So from the point of view of an individual maintainer, I see where you're coming from. But I have a problem with the practice of regenerating these files when the broad application of this practice winds up presenting a serious impediment to upgrading one of these build tools in Fedora. That didn't have to happen. But if all you did was run "automake", I'm pretty sure upgrading libtool won't break your package. In fact, I'm not even sure that running "autoreconf" (without arguments) is sufficient to incur breakage. What is nearly guaranteed to cause breakage is running "autoreconf -f". And not only is it likely to cause breakage, it's going to be completely unnecessary in all but *very* unusual cases. I can accept that my objectives for resiliency may not be shared by all packagers. I think it's possible to craft a guideline that steers packagers toward less deleterious invocations of the autotools (when they feel the need to do so at all). But before trying to make any further progress on this, I want to have a look at the packages that a libtool2 upgrade stands to break. -- 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
