Hello fellow developers, We've had a few problems with widespread deployment of outdated config.guess and config.sub files, which result in some archs not being supported. So far, the only solution available to this problem was to file a bug against every package with outdated files everytime a update is needed.
I've assembled a package, "autotools-dev" that tries to address this issue. It is available at http://people.debian.org/~hmh/ (not an apt repository). The package diverts the outdated files /usr/share/automake/config. {guess,sub} and /usr/share/libtool/config.{guess,sub}, and supplies up-to-date files from CVS (there is a 2001-04-20 update supporting sparcv9b for example) in their place. An debhelper helper script, dh_autotools is also provided. If a call to dh_autotools is added at the beginning of the "clean" target of debian/rules, it updates existing config.guess/sub files in the source package to the newest ones provided by autotools-dev. The clean target was choosen because it is called by dpkg-buildpackage before the call to dpkg-source to build source packages. The issues addressed by autotools-dev are: 1. The Debian automake package has failed to provide us with a good source of updated config.{guess,sub} files, to the point that the libtool maintainer started providing his own copies. Autotools-dev takes the duty of providing up-to-date config.{guess,sub} out of the hands of the libtool and automake packages. Being a small and very straightforward package, it is extremely easy to keep it updated (a simple debian/rules cvsfetch in autotools-dev will do 99% of the work, actually). 2. Many maintainers are not aware of the problem with outdated config.{sub,guess} files, and most of the time, their upstream isn't either. This can result in _very_ outdated files being used even in new packages. Forcing all packages using autoconf/automake to update often their config.guess and config.sub files through dh_autotools or some other (automated) method fixes this (I'm thinking about a policy proposal with a "should" to increase awareness of the problem AND force people to adopt a one-time change solution instead of just dumping new copies of the file and forgetting about it 'till the next breakage). Obviously, all config.{guess,sub} packages would have to build-depends on autotools-dev for that to work. That is an acceptable tradeoff IMHO. Any thoughts on the issue? Comments about dh_autotools and the autotools-dev package? If not, I'll upload it to the archive and request debmake and dh_make to use it (so as to 'contaminate' new packages right from their birth), as well as sending a policy proposal. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
pgplHAuoocyW4.pgp
Description: PGP signature
