On Thu, Jun 13, 2002 at 12:32:51PM +0100, Scott James Remnant wrote: > Amusingly enough, I've had exactly the same problem over the last couple > of weeks sorting this mess out on our build farms at work... The Debian autobuilders have tangled with it too. There really aren't that many things which break and what breaks is trivially fixable. > > - 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. > > > I would be inclined to agree. I've not found anything that requires > automake 1.5, the package either works with 1,4 or with 1.6. I've seen 1.5 requirements, but again they all work with 1.6 as well. Since 1.6 is just a bugfix and futureproofs the generated buildsystem against further possible incompatibility, it's the correct solution.\ > > 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. > > > Agreed, both automake packages should include an "automake" executable, > as both autoconf packages should include an "autoconf" one. I would be > inclined for it to be an alternative pointing at automake1.6 by default, > so anyone who can't get their package ported can still run "automake1.4" > (or change the alternative). I don't think we're quite ready for that yet. I would suggest making automake 1.4 a priority of perhaps 10 and 1.6 perhaps even 5. 1.6 can be given a priority of 20 in the future once more of the distribution works with it and more things are inclined to use 1.6.. > Priorities should really be the same for autoconf2.13 and autoconf2.5. Now the suggested change I had for automake 1.4 - making it look for a versioned binary as 1.6 does and falling back for compatibility on other systems which don't have them - is probably even more important for both versions of autoconf. We have no way for automake1.6 to depend on the autoconf alternative being 2.52+ otherwise. > > 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. > > > The trouble with the 1.4->1.6 conversion is that it often requires some > autoconf 2.13->2.5 conversion as well. This is also generally trivial. Not as easy perhaps as the automake transition itself, but I've yet to see a script I could not port to either automake1.6 or autoconf2.50 in twenty minutes, plus the time taken to read and understand the current scripts. (Some of those configure.ins are completely gross..) > automake1.5 should be ignored. It cannot be ignored completely because we've already got packages which depend on it at compile time. But that's even more trivially fixable. -- Joseph Carter <knghtbrd@bluecherry.net> This end upside-down <evilkalla> heh, I never took a coding class <evilkalla> or a graphics class <evilkalla> or a software design class <vegan> and it shows :P
Attachment:
pgpyHCDsy6_05.pgp
Description: PGP signature