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
Attachment:
pgpSgu76dnDKw.pgp
Description: PGP signature