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 <email@example.com> 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.
Description: PGP signature