[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The automake issue, and why crippling 1.6 is a bad plan

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

Reply to: