On Thu, Jun 13, 2002 at 08:49:23PM -0400, Eric Dorland wrote: > > 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? They are supposed to be. A few bugs in 1.5 don't break things anymore, but I hesitate to call this a problem. ;) 1.6 requires that you use autoconf 2.52+ of course, so the scripts must also work there. I suspect it's possible to have a script which works with automake 1.5 but not autoconf 2.52, but I've never seen one. > > - 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... Provided the package actually gets into the archive soon, I intend to. > > - 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. If the scripts are not regenerated, the discussion is moot. Packages which do not regenerate these things don't have to worry about needing to do so. > > - 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. 1.5 provides automake already. While this has caused some problems, it has not, in practice, caused any problems which were not quickly 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. The autoconf1.4 docs probably need to be modified to provide a versioned info file. As I said, autoconf 2.13 does the same. > > 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. Then they're wrong. Problems like an automake transition don't fix themselves because a few people say that they should. When upstream breaks something, we're left with the responsibility to our users to actually fix it, rather than to simply declare the thing broken and deciding to leave it that way. > Compatibility is important. I have no desire to break things, but > fixing the dependencies is definitely a good idea. As several people keep saying (though I don't agree), packages should never mess with autotools directly in the build scripts. If that is so, then there is nothing that should need fixing. Since that's not so, these packages need to be tested for problems, possibly fixed. I don't know what to say about the elitists in the project who have decided it's broken, they like it that way, and that those who would fix it do not have permission to do so, except that the day I do not have permission to fix bugs is the day I may as well be tossed out of the project, because that's supposedly a good part of what we all say we're doing here in the first place. But then, I have discovered that some people reject my patches because they are my patches outright, and then go and deliberately reimplement sometimes much later the exact thing my patch did, just because they didn't want a patch from me in their package.. Debian politics, fast at work, bringing you a quality distribution! -- Joseph Carter <knghtbrd@bluecherry.net> My opinions are always right <Shinobi> There are worse things than Perl....ASP comes to mind
Attachment:
pgpqOGVel8jPB.pgp
Description: PGP signature