On Thu, Jun 13, 2002 at 07:17:03PM +0200, Simon Richter 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.
I test the things I develop with automake 1.4, 1.5 (now 1.6 instead), and
both autoconf 2.13 and 2.50. This includes Debian and non-Debian stuff.
I do not feel it is acceptable for the things I work on to simply fail to
work, regardless of which version of autowhatever you've got installed,
provided that you've got some sane minimum version.
This is the approach I advocate for Debian, though maintainers are free to
use whichever version of the tools they deem appropriate.
> > - 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.
No, they don't. Most autogen.sh's and bootstrap's and other such scripts
in people's CVS call automake and expect that script to be in the user's
path and do something useful. The current automake1.6 packages, at the
insistance of a few people who are dead set against the automake1.6
packages actually being useful for any practical purpose, lack any such
thing.
It is the scripts written for automake1.6 only which actually use the
versioned automake. And they're correct to do so - that's what it's there
for. But those versioned scripts are not useful to the rest of the world,
which expects automake and aclocal to be in the path and work.
> > - 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". :-)
1.5 works? It's called automake too. If your problem is that you simply
don't want to do the work necessary to make your scripts portable across
versions, then other people have offered to do this work for you, several
times over the past week.
In fact, I'll be doing that work on any package I find broken, whether you
like it or even want it done. Patches will be sent upstream and to the
Debian BTS. If ignored in the BTS, I'll NMU. Simple as that, because
this is a real problem and it needs a real fix rather than more Debian
trademark political bullshit trying to prevent adoptation of a version of
software several of us happen to not like.
> > 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.
It's at least as compatible as 1.5 is. Possibly more so, given that some
of the things which 1.5 broke were fixed.
> > 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.
And what about 1.7? How many years can we expect to depend on an old,
broken version of automake? At what point do we move on and accept that
1.6 is currently the recommended version to target and start doing so?
Yes I realize not many other people use 1.6 currently. They're all
waiting for their OS to transition to it. Some have, Debian hasn't. And
by your non-solution, Debian never would. Debian tends not to fix
problems when non-solutions get chosen as "good enough for now", and this
is one non-solution I don't want to see enshrined for all enternity.
> > 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.
Ohh, all of those terrible incompatibilities you've heard about, but never
yourself seen! Most of it is outright FUD. Thank you for contributing to
more of it without actually knowing WTF you're talking about! I'm sure
the guys at the GNU project appreciate it as much as I do.
Maybe if you and just about every other person screaming "incompatible!"
actually knew what changed and how this sometimes breaks things (and more
importantly, how this doesn't break things and keeps future things from
breaking), one might think that you'd be a little more inclined to not try
to kill off this new version without actually using it first.
> > 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).
When I say automake, I mean automake. Any version, from 1.4 on. And if
you use 1.5 or 1.6, things just happen to work better.
Specifically for Debian, I now check for the existance of the -1.6 scripts
and set an appropriate DEBFUCKUP variable to -1.6 which gets appended to
the names of automake and aclocal. And I document why this is necessary
for Debian systems ONLY, and why this is just about the stupidest thing
Debian could possibly do:
- It prevents new features from being used because it guarantees that, on
a Debian system, a script will never find automake a non-broken
automake with support for the new features.
- It pretty much prevents any scripts from being written which are
compatible with both versions because you must choose between
automake1.4 and the docs for 1.6.
- It breaks the common case for the end user. While Debian can expect to
need to do many convoluted things to ensure that all of our packages
work, we should never break the common case for the user trying to
build a program! Other dists have had releases unsupported by software
authors because they've had things broken in the build system. Do we
really want the same to be said of Debian?
If a user comes to me and says he can't compile my code because autoconf
or automake are missing, I'll ask him if he's installed the package. If
he says he has and it still doesn't work, I'll tell him to get a dist that
isn't fucked up. Now at least with Debian I know what's fucked up because
I happen to use it, and I've already guarded versions of my packages in
CVS against it. But I shouldn't have had to.
--
Joseph Carter <knghtbrd@bluecherry.net> Certified free software nut
<liiwi> so, what's the official way to get buildd to retry a package? prod
it with a stick?
<Joey> prod neuro
<liiwi> with a stick?
<Joey> yes.
Attachment:
pgpF_6Yf965a1.pgp
Description: PGP signature