On Sat, 2008-10-11 at 21:35 +0200, Till Maas wrote: > On Sat October 11 2008, Braden McDaniel wrote: > > On Sat, 2008-10-11 at 20:31 +0200, Till Maas wrote: > > > On Sat October 11 2008, 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. > > > > > > There is a draft about this at: > > > https://fedoraproject.org/wiki/PackagingDrafts/AutoConf > > > > Thanks. I've edited this a bit to include references to libtoolize. I'd > > be happy to help move this forward. What's required? > > You have to write an e-mail to the fedora packaging commitee and discuss it > with them: > https://www.redhat.com/mailman/listinfo/fedora-packaging Okay. > > > > 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. > > > > > > I have read either in the wiki or on this mailing list, that one should > > > run autoreconf locally and create a patch from this, that is then used > > > within the spec. > > > > That is, generally, the right idea. However, autoreconf is a bit of a > > sledgehammer and can result in a patch that is larger than necessary. > > The only files that should need patching are configure and Makefile.in. > > autoconf will produce the former, and automake the latter. It is more > > unusual, but possible, that ltmain.sh might need patching. libtoolize > > can be used to generate a patch in that case. > > So the one would run autoreconf, but only create a patch for configure, > Makefile.in and ltmain.sh? Or should only automake and autoconf be run in the > normal case and then the diff is the patch? I'm not sure what's considered the "normal case" here. * If you've only modified Makefile.am, you can just run automake to regenerate Makefile.in. * If you've modified configure.[ac|in], but you didn't add any new macro invocations, you can just run autoconf. * If you've added macro invocations to configure.[ac|in], you need to run aclocal before running autoconf. In any of these cases, there's no reason for your patch to include modifications to files other than configure and Makefile.in. autoreconf is the shotgun approach. It exists as a convenience to developers, when running the individual tools in the right order can be tedious. Patches should be surgical. So for the purpose of generating diff input, I'd suggest running the tools individually. Needing to modify ltmain.sh is *really* unusual. If you're trying to surgically correct some behavior of the version of libtool used to build the upstream source package, it's exactly the right thing to do. If you *really* need to use a different version of libtool than upstream used, we're in choppier waters. I think there's a case to be made for just invoking libtoolize in the spec file for this purpose--but you should proceed fully aware that your package will get whatever Fedora's "latest" libtool happens to be and there is a very real possibility (probability) that things will break. Using a patch will be more future-proof; but that patch is going to be big and unwieldy. Really, the best thing you can do in such a scenario is reexamine the choices that brought you to that place and realize, "What was I thinking?!" > Maybe you can add whatever should be done to the AutoConf wiki page. I'll do that. -- 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
