Autoconf best practice in Debian

This page gives some tips to packagers on how to use autoconf when packaging.

Particularly with regard to updating autofoo to cater for new architectures.

The issue

The autotools design is that you ship a version of the auto* files with your packaged tarball and that is used until you do a new release. This model doesn't work well with mature software that is not often released and new Debian architectures/ports, because the configure stuff shipped with the package has never heard of the new arch so refuses to build.

For the vast majority of packages, all that is needed is to update the config.sub and config.guess files which contain all the arch-specific bits. Debian does ship system config.sub and config.guess files, to be used, but unfortunately autoconf will always use the ones in the package in preference if they exist. Doing this in theory put the config.* files out of sync with the rest of the autofoo release, but in practice it is extremely rare for this to cause a problem. In general you are much better off building against the current versions of these files than the ones shipped with the tarball.

Sometimes just updating these files is not enough and the package needs a full autoreconf to regenerate various files in order to build correctly for the new arch. Hopefully as the packager you will have some idea of whether this might be needed in your case. If not, just try the simple fix first and the more thorough one if that doesn't work. This is more likely to cause some other build issue due to newer autoconf doing things differently from how the build was tested. Obviously the bigger the jump in autotools releases, the more likely there is to be a problem. Again, in practice just updating the tools normally works fine these days, and many packages build with 'current' as a matter of course.

Updating config.{sub,guess}

The best way to update things depends on the tools used by Debian rules. (Plain make, debhelper, dh, cdbs etc), and also on the complexity of the package. Some have multiple copies of config.{sub,guess} in the build tree, and this sometimes complicates matters so you have to explicitly update them (and not just the top-level).

Here are some examples of ways to update things.


This is often a very simple matter of using --with autotools-dev

% dh --with autotools-dev

will often just DTRT (by using dh_autotools-dev_updateconfig and _restoreconfig in the right places).


 config.status: configure
+       dh_autotools-dev_updateconfig
        QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2
        touch aclocal.m4
        touch configure

        rm -f build-stamp
        [ ! -f Makefile ] || $(MAKE) distclean
        QUILT_PATCHES=debian/patches quilt pop -a -R || test $$? = 2
+       dh_autotools-dev_restoreconfig


If using the standard CDBS support it should update config.{sub,guess} automatically:

include /usr/share/cdbs/1/class/


You can just add a patch to the config.sub and config.guess files, but this will break next time they are updated upstream. It does deal with dpkg-source objecting that you have changed the files.

A better scheme is simply not to ship a config.guess/sub at all and copying in the system versions out of /usr/share/misc. This needs a build-dependency on autotools-dev, which supplies the system files.

Updating configure