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-...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224140005.1773.15130.report...@stoneboat.aleph1.co.uk
