On Sat, 2008-10-11 at 15:43 -0400, Steve Grubb wrote: > On Saturday 11 October 2008 15:18:33 Braden McDaniel wrote: > > 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. > > There's been a number of occasions where I patch Makefile.am because its a 1 > liner and patching Makefile.in makes a very ugly patch that becomes harder to > read. Many one-liner Makefile.am patches are also one-liner Makefile.in patches when Makefile.in is modified manually. There's no reason to be shy about doing that. Note also that, for better or for worse, Fedora includes several older versions of autoconf and automake. This is one time it's for the better. You can use a version of autoconf or automake that is reasonably close to (but not older than) the one the upstream developer used when regenerating the files, thus minimizing noise in the patch. > Examples of this is adding files to be compiled in, removing files to > be compiled in, or making something optional for a configure flag. So, if you > know what you are doing, its fine to patch configure.ac or Makefile.am. It's really not. Because even if you're perfectly capable using the autotools, you're still exposing the package to potential breakage when it gets rebuilt with a newer version of the tools. > On the otherhand...there are also a number of projects that use libmissing. We > do not carry that in Fedora. That means that any project using libmissing, > you always have to patch Makefile.in and not Makefile.am since autoreconf > won't be able to find the m4 macros for gnulib. We should probably carry > gnulib sooner or later. I was thinking that Fedora should package gnulib just the other night. But not so that spec files could use gnulib-tool (or similar). That's just as broken as using autoreconf--and for exactly the same reasons. -- 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