[debhelper-devel] Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Wookey]

Package: debhelper
Severity: wishlist

Every new port involves hundred of patches to packages updating
config.sub and config.guess so that packages build on the new arch.

The autotools-dev package provides extremely handy functionality which
allows this to be fixed in a clean and generic way, by 
1) for debhelper packages:
adding dh_autotools-dev_updateconfig to each configure target
adding dh_autotools-dev_restoreconfig to each clean target

2) for dh packages:
adding --with autotools-dev to the dh invocation

(modulo some exceptions where something more fiddly is needed).
This adds a build-dep on autotools-dev in each case.

See http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=arm64 for hundreds of example of this.


Debian would be much improved in this regard if the default debhelper
set of things run included the dh_autotools-dev rules. Individual
packages wouldn't need patching if they already used debhelper or dh -
it would just work. Overrides could be added to deal with the unusual
cases, and a --without autotools-dev to disable it.

build-from-source distros like OE have been doing this by default for
many years and it works very well, removing an enormous amount of
friction from new ports.

Is there any reason not to make this a default behaviour? I am not aware
of this ever causing a problem with package builds, even where the
config.{sub,guess} being replaced are very old. This is much more
conservative than doing a full autoreconf, which regularly does break
things, and would be a controversial thing to do by default.

Having automatically-updated config.{sub,guess} in all debhelper-using
packages would be a huge boon to porters particularly, but also package
maintainers in general as they won't get bothered by these bugs and
build failures.

It would add a dependency on autotools-dev to debhelper, but that's a
very simple package with just a few files so I don't see that as being a
big burden.

Pabs did try (last year) to get this 'default updating of
config.{sub,guess} for distros' behaviour moved upstream into autoconf
so that if distro versions of the files were present then they would be
used. But upstream did not want to make this automatic (because it
included distro-specific path knowledge), so an env var containing the
path still has to be set to get this behaviour, which means we would still
have to modify either build tools or individual packages to set that,
and it would still only work on packages that already use a very
recent autoconf (which is the small set that don't need fixing anyway as
they are already up to date). So this may well become a useful feature we
can depend on in a few years time, but in the meantime I favour having
debhelper just DTRT.

This does seem like a good example of something where the right default
(for autotools-using packages) is to use the system versions of these
two files, not the ones shipped with the (possibly very old) source.
Exceptions to this are very rare (I don't know of any) so it seems like
a good candidate for debhelper to do it by default.

cc:ing to debian-devel for wider input.

-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages debhelper depends on:
ii  binutils    2.22-8
ii  dpkg        1.16.12
ii  dpkg-dev    1.16.12
ii  file        5.11-2
ii  html2text   1.3.2a-15
ii  man-db      2.6.2-1
ii  perl        5.14.2-21+deb7u1
ii  po-debconf  1.0.16+nmu2

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  <none>

-- no debconf information