Automake 2.50 test summary (was: Re: Proposed Autoconf 2.50 path)
Okay, this is what we've got. I took the 197 packages that
declare Build-Depends: on autoconf, and tried (on klecker)
running autoconf-2.50 in the top-level directory of each of them.
The results were:
* 124 ran autoconf-2.50 successfully, though some of them
produced warnings.
* 37 had errors that caused autoconf-2.50 to return
unsuccessfully.
- 4 of these also errored out under autoconf-2.13.
- 6 of these were obviously KDE packages. (KDE
has a bug in its Autoconf fragments which is
apparently now fixed in CVS.)
(Two packages are in both subgroups above.)
- Some of these packages passed when I first ran
aclocal and automake to get other files
updated. Some more might pass if I ran
whatever libtool uses for configuration as
well.
* 36 packages didn't have a configure.in at their top
level.
- For most of these, this was because these
packages contained tarballs of their actual
sources which are unpacked at build time (e.g.,
db2).
- Others have no apparent connection to Autoconf
at all (e.g., libarr). WTF?
- At least one package (bibtex2html) contains a
configure script but not the corresponding
configure.in, possibly a GPL violation. Double
WTF?
My conclusion is that the number of packages that will actually
have problems is smaller than claimed. 37 packages isn't very
much: it's only 23% of the 161 packages that had a configure.in
at top-level.
I am thinking about just filing bugs against the packages with
errors, suggesting that they be updated or adapted for use with
the autoconf2.13 package.
Other opinions?
--
Ben Pfaff <pfaffben@msu.edu> <pfaffben@debian.org> <blp@gnu.org>
MSU Graduate - Debian GNU/Linux Maintainer - GNU Developer
Personal webpage: http://www.msu.edu/user/pfaffben
Reply to: