On Saturday 11 October 2008 20:40:14 Braden McDaniel wrote: > > 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. What if you are cherry picking a patch in upstream cvs/svn to fix a bug that upstream won't be releasing for a while? They are usually patches against Makefile.am if they touch that file at all. > Note also that, for better or for worse, Fedora includes several older > versions of autoconf and automake. I think that is for worse. I have tried many times in the past to get rid of old autotools so that people move to the new ones. Just having old autotools in the distro encourages clinging to the past. We need to purge the old ones and move on. Let's stop maintaining 6 copies of automake and 3 copies of autoconf. I've also seen times when you had to regen the auto files because the config.guess file was too old. > > 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. That's where a developer's duties begin. You have to look at the output and decide if it were safe. In some cases you have to forward port the Makefile.am and configure.ac files. I usually send those upstream so that they can stop requiring the use of old tools. Since Fedora is cutting edge, I think we should be actively helping the old files move forward. I don't mind seeing guidelines published for people that find autotools a mystery. But I don't think we should be making any policy about what a developer does to maintain his packages. If something blows up we shold just file a normal bug against it. -Steve -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
