Suggested packaging guideline: avoid running autoreconf

[Steve Grubb]

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