Okay, let's see if we can put this as simply as possible, for everyone
involved:
automake 1.4 has existed for ages, and allows certain things to be done
which upstream has decided to no longer permit in automake 1.5+. This can
break packages in odd ways, most notably a ./configure file which contains
invalid shell script. This is ... very bad.
Debian had an automake package which was 1.5, but this was quickly
reverted to 1.4 for the woody release. The details of this don't matter,
except that we ended up with a package automake which provides automake
1.4 and a package automake1.5 which provides 1.5. This means the problem
is already out there and is pretty significant in those few cases it has
popped up. Two ever so slightly incompatible packages providing automake
already exist today. At least some scripts are known to work in 1.4 and
not 1.5, and certainly 1.5 scripts may not be written to use features not
in 1.4. We would hope that all of these depend on automake1.5, but I'm
guessing the autobuilders have found this not always so.
Enter automake 1.6, a bugfix for 1.5 which happens to depend on the new
version of autoconf (which is the primary reason it was not called 1.5.1
so far as I'm told..) It introduces an internally-used versioned-binary
to hopefully prevent future automakes from breaking existing reconfigure's
when they don't have to. 1.6 is fully compatible with 1.5, so 1.5 should
go away now.
The real problem is that 1.5 still exists, even if the package goes away
today. It can still be /usr/bin/automake, and the incompatibilties which
have been so hyped are already being experienced by people on the few
packages which actually happen to have them. We can't ignore the mess 1.5
created, nor 1.6 which unfortunately doesn't clean it up. We also can't
ignore that 1.4 is still used by most developers upstream, even if that
has started to change. What this means for us, IMO, is:
- automake1.5 should be dropped, 1.6 is compatible with 1.5 and is a
suitable bugfix release. Since not many packages build-dep on 1.5,
now's the time to recompile them with a versioned dep on 1.6.
- The internal versioned binary used by automake 1.6 is probably a very
good thing. We should investigate whether or not it's practical to
add this support to our 1.4 packages, though they would have to fall
back to using non-versioned scripts if versioned ones are not
available. (Compatibility with other dists...)
- It'd probably be wise to replace automake with automake1.4 and have
automake be a virtual dependency.
- Because proper documentation on building scripts for both 1.4 and 1.6
versions of automake does not exist, both versions' documentation
should be installable. This is done currently with autoconf (though
pinfo seems to crash often with autoconf2.13's docs) and has been a
great help making sure that scripts will run under both versions.
Co-existing docs are more important than co-existing automakes.
Once again, there is no automagic way to fix this problem. The genie is
already out of the bottle and causing a few problems here and there (but
in large, NOT causing problems, which is perhaps more important..) The
compatibility broke at 1.5, not at 1.6. The only real option available to
us is to try and make things work, and fix the cases where it doesn't.
It is also quite broken for automake1.6 not to provide /usr/bin/automake.
since basically nobody uses the versioned scripts yet. This is not a
matter of what Debian packages should use, but rather what should be
available to our users. A low-priority alternative is most certainly
called for. An automake which fails to provide automake isn't much good
to anybody. I do not see how this is non-obvious, but it seems to need
saying, so there you have it: A package claiming to have a thing should
have it, preferably in a manner in which it is expected to be found. This
is especially true if that expectation is made by several thousand scripts
Debian did not write.
Once again, this leaves the unknown packages which probably work just fine
with automake 1.6, but might not. If a list was generated for packages
which did not work with 1.5, it may still apply. These packages need to
be tested and those which fail need to be fixed. Out of thousands of
packages, I expect only a handful to require any substantive patches at
all. Of course even if every Debian package were converted to use 1.6
tomorrow, we'd still need 1.4 for some time yet. Just not several years
from now when the rest of the world is using automake3.14 or so.
If you don't like my opinion of the situation or my proposed solution,
that's too bad - suggest something better which actually deals with the
real problems already! So far I've only seen lots of things that won't
work for all cases, or even most of them. We need solutions which work
for as many cases as possible, with the end user running ./autogen.sh out
of some CVS tree being pretty high on the list of things that need to
work.
I'm quite fed up with seeing demands that the autoconf1.6 package be
crippled, especially given the excuse of "compatibility reasons",
something which is not at all really fixed by crippling the 1.6 packages
because the 1.5 packages already exist and both have been and are being
used today. We can cover our ears and hum real loud, but that won't fix
the problem. It should be fixed, and fixed right.
--
Joseph Carter <knghtbrd@bluecherry.net> Do not write in this space
<Sammy> that's *IT*. I'm never fucking attempting to install redhat
again.
<Sammy> this is like the 10th fucking machine on which the installer has
imploded immediately after I went through the hell of their
package selection process.
<timball> Sammy: just use debian and never look back
<Sammy> timball: debian iso's are being written at this very moment.
Attachment:
pgpiwSA4FcMm0.pgp
Description: PGP signature