Suggested packaging guideline: avoid running autoreconf
Steve Grubb
sgrubb at redhat.com
Sun Oct 12 13:32:31 UTC 2008
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
More information about the fedora-devel-list
mailing list