[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



* Joseph Carter (knghtbrd@bluecherry.net) wrote:
[snip] 
> 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.

Are they fully backwards compatible? is this documented somewhere?
 
> 
> 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.

This would be good :) go right ahead...

>   - 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...)

There is a patch to do this I believe, but i'm not sure how well it
works... and it doesn't solve the problem of scripts that have already
been generated.

>   - It'd probably be wise to replace automake with automake1.4 and have
>     automake be a virtual dependency.

Yes, but then no other automake package can provide automake until all
the dependencies are fixed.

>   - 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.

I'm not sure its as critical as you seem to think, but it would be
nice. Unfortunately automake 1.6 doesn't provide versioned docs, so
we'd have to hack them up, or make them a separate conflicting
package. I asked the automake list about this, but I got no response. 
 
> 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.

I agree here too, but I think many don't.
 
 
> 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.
> 

Compatibility is important. I have no desire to break things, but
fixing the dependencies is definitely a good idea.

-- 
Eric Dorland <dorland@lords.com>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
------END GEEK CODE BLOCK------

Attachment: pgpx7qg5z4NLD.pgp
Description: PGP signature


Reply to: