Re: The automake issue, and why crippling 1.6 is a bad plan
On Thu, 13 Jun 2002, Joseph Carter wrote:
> 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.
Well, I'm currently going back to autoconf 2.13 and automake 1.4 for my
packages, since they still work and make the lives of the people who want
to install my software (as if there were any) easier, are generally faster
and cause less trouble with Debian packaging as they do not drop cache
directories all over the place.
> - 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...)
Upstream developers who use AM 1.6 call it by its versioned name when
generating the Makefile.ins, and IIRC these know that they should rebuild
themselves with the versioned name, too. So I don't se a real problem
here.
> - It'd probably be wise to replace automake with automake1.4 and have
> automake be a virtual dependency.
I like the current state. The working version is called "automake". :-)
> 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.
I disagree. AM 1.6 is not compatible enough to be an "alternative". Since
you only need to know the difference if you are starting a new package (or
adding a directory to one) using AM 1.6, I don't think this is a real
issue. If you are simply patching Makefile.ams, you don't see the
versioning. But it would be truly annoying if autobuilds failed because of
this.
> 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.
These scripts either know the version number or expect a 1.4
compatibility, unless they are written for 1.5, in which case they should
be fixed for 1.6.
> 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!
I don't really see any problems other than the ones caused by the 1.5
incompatibilities, and fixing those is IMNSHO not our problem, but the GNU
project's. They have come up with a solution which might actually work (I
haven't tested it, AC 2.50/AM1.5 scared me off), so we shouldn't break it
again.
> 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.
autogen.sh uses "automake" if upstream meant 1.4 or 1.5. In the former
case, it is good if AM 1.6 does not provide a "automake" binary, in the
latter case, upstream should replace the call with a call to
"automake-1.6" (as 1.6 is supposed to be compatible with 1.5, that should
be a trivial fix).
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: