State of automake packages

[Jordi Mallach]

[beware, yet another "this package has been unmaintained for long post]

What's up with the automake packages?

Since aj reverted the automake 1.5 upload and added automake1.5, there
haven't been any maintainer uploads (at least for 1.5), and the bugs at
the bts have been piling up, including some nasty ones.
automake 1.6x was released long ago, but we don't have it packaged
still, and this is holding the updates for some other packages,
including libgcrypt 1.1.7, which is needed by gnutls 0.4.x, which is
needed by newer mutt-gnutls patches and wmbiff, just to name the case
that affects me.

So, is the maintainer interested in updating these, or should someone
else takeover? (I'm not volunteering, though, but I guess there would be
plenty of takers).

How handle automake now that Woody is frozen is another question. Will
automake get back to being the latest version? I guess it's the right
moment to break things in unstable.

Thanks,
Jordi [shielded behind zarq :p]

[Scott James Remnant]

Post by Jordi Mallach
What's up with the automake packages?

The initial problem at least is that "compatible" is not a word most
people choose to describe automake 1.4, 1.5 and 1.6.

Post by Jordi Mallach
How handle automake now that Woody is frozen is another question. Will
automake get back to being the latest version? I guess it's the right
moment to break things in unstable.

If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

Scott

[Ivo Timmermans]

Post by Scott James Remnant

Post by Jordi Mallach
What's up with the automake packages?

The initial problem at least is that "compatible" is not a word most
people choose to describe automake 1.4, 1.5 and 1.6.

That's not really the point. Currently there are two automake
packages, automake (version 1.4) and automake1.5. automake 1.6 has
been available for some time, but hasn't been uploaded into sid yet.
One of my packages requires it, which is keeping some other packages
out of sid.

Post by Scott James Remnant
If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

Maybe, but some packages do require 1.5 or 1.6.


Ivo

[Eric Dorland]

Well 1.6 actually takes these incompatibilities into account and
actually provides a binary called automake-1.6 and has other
mechanisms to smooth these API changes in the future. Anyway, it
wouldn't be too difficult to package automake1.6 alongside the other
two packages. I volunteer unless Kevin Dalley pipes up and says he
wants to do it.

Post by Ivo Timmermans

Post by Scott James Remnant

Post by Jordi Mallach
What's up with the automake packages?

The initial problem at least is that "compatible" is not a word most
people choose to describe automake 1.4, 1.5 and 1.6.

That's not really the point. Currently there are two automake
packages, automake (version 1.4) and automake1.5. automake 1.6 has
been available for some time, but hasn't been uploaded into sid yet.
One of my packages requires it, which is keeping some other packages
out of sid.

Post by Scott James Remnant
If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

Maybe, but some packages do require 1.5 or 1.6.
Ivo

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Jordi Mallach]

Post by Eric Dorland
Well 1.6 actually takes these incompatibilities into account and
actually provides a binary called automake-1.6 and has other
mechanisms to smooth these API changes in the future. Anyway, it
wouldn't be too difficult to package automake1.6 alongside the other
two packages. I volunteer unless Kevin Dalley pipes up and says he
wants to do it.

That'd be great. It'd be even better if all the automake packages could
be cleaned up and updated. Kevin, are you around?
If Kevin can't, it'd be nice if someone (you? :) could take them give
them some love.

Jordi

[Eric Dorland]

Post by Jordi Mallach

Post by Eric Dorland
Well 1.6 actually takes these incompatibilities into account and
actually provides a binary called automake-1.6 and has other
mechanisms to smooth these API changes in the future. Anyway, it
wouldn't be too difficult to package automake1.6 alongside the other
two packages. I volunteer unless Kevin Dalley pipes up and says he
wants to do it.

That'd be great. It'd be even better if all the automake packages could
be cleaned up and updated. Kevin, are you around?
If Kevin can't, it'd be nice if someone (you? :) could take them give
them some love.

Well I have plenty of love to give them :) But I'm horribly reluctant
to steal any packages out from underneath someone's nose. I suppose
I'll email him privately (actually CC him this mail) and if he gives
his blessing or does not respond I'll package 1.6. If he is still
unresponsive after that is all said and done we can consider him MIA?
Do people think that is fair? I'm not actually sure he's MIA, that's
just the general sense I'm getting from this thread.
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Jordi Mallach]

Post by Eric Dorland
Well I have plenty of love to give them :) But I'm horribly reluctant
to steal any packages out from underneath someone's nose. I suppose
I'll email him privately (actually CC him this mail) and if he gives
his blessing or does not respond I'll package 1.6. If he is still
unresponsive after that is all said and done we can consider him MIA?
Do people think that is fair? I'm not actually sure he's MIA, that's
just the general sense I'm getting from this thread.

I'm not sure if I finally mailed Kevin some months back about this. I
probably forgot, but at least Ivo mailed him recently, no reply still.

Cowchelon says nothing. The BTS shows no recent activity, but I didn't
look too carefully.

Jordi

[Eric Dorland]

Hi everyone,

Well I've packaged automake 1.6. It seems Steve Robbins beat me
slightly to the punch (http://people.debian.org/~smr), but I believe
my packages to be superior since it uses debhelper and will
(theoretically) install in parallel to automake 1.4 and 1.5.

Here are my thoughts on what to do to fix the current automake
packages in sid. For those who don't know, the major problem is that
automake 1.4 and 1.5 have various incompatibilities, and they cannot
be installed side by side. Automake 1.6 and later versions don't
suffer from this problem, since they provide versioned binaries.
Hacking 1.4 and 1.5 to install side by side may be possible, but for
now they conflict.

The first thing that needs to be done is to upgrade the 1.4 and 1.5
packages to their newer upstream versions to hopefully close some
bugs. They should be changed to conflict with each other, but not all
versions of automake. I think /usr/bin/automake should be an
alternative, with automake 1.4 having the highest priority.

What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded. Kevin (the
current automake maintainer) seems unresponsive. Should I NMU them for
now, or actually take them over?

Post by Jordi Mallach

Post by Eric Dorland
Well I have plenty of love to give them :) But I'm horribly reluctant
to steal any packages out from underneath someone's nose. I suppose
I'll email him privately (actually CC him this mail) and if he gives
his blessing or does not respond I'll package 1.6. If he is still
unresponsive after that is all said and done we can consider him MIA?
Do people think that is fair? I'm not actually sure he's MIA, that's
just the general sense I'm getting from this thread.

I'm not sure if I finally mailed Kevin some months back about this. I
probably forgot, but at least Ivo mailed him recently, no reply still.
Cowchelon says nothing. The BTS shows no recent activity, but I didn't
look too carefully.
Jordi

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Junichi Uekawa]

Post by Eric Dorland
The first thing that needs to be done is to upgrade the 1.4 and 1.5
packages to their newer upstream versions to hopefully close some
bugs. They should be changed to conflict with each other, but not all
versions of automake. I think /usr/bin/automake should be an
alternative, with automake 1.4 having the highest priority.

Hmm.. it's not an alternative if it is not compatible.
It's like bison and yacc, gpc and gcc.

They are alternative ways of doing one thing, but they are not
necessarily compatible.

I don't see problems with having different packages conflicting
with each other.

regards,
junichi

[Eric Dorland]

Post by Junichi Uekawa

Post by Eric Dorland
The first thing that needs to be done is to upgrade the 1.4 and 1.5
packages to their newer upstream versions to hopefully close some
bugs. They should be changed to conflict with each other, but not all
versions of automake. I think /usr/bin/automake should be an
alternative, with automake 1.4 having the highest priority.

Hmm.. it's not an alternative if it is not compatible.
It's like bison and yacc, gpc and gcc.

Well to some degree they are compatible. I think a better analogy
would be the various vi clones. They all sort of do the same things,
but they are not necessarily compatible.

Post by Junichi Uekawa
They are alternative ways of doing one thing, but they are not
necessarily compatible.
I don't see problems with having different packages conflicting
with each other.

Well the point is newer versions of automake do not need to conflict
with each other.

Post by Junichi Uekawa
regards,
junichi

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Junichi Uekawa]

On Sun, 9 Jun 2002 14:15:59 -0400

Post by Eric Dorland

Post by Junichi Uekawa
Hmm.. it's not an alternative if it is not compatible.
It's like bison and yacc, gpc and gcc.

Well to some degree they are compatible. I think a better analogy
would be the various vi clones. They all sort of do the same things,
but they are not necessarily compatible.

I had an impression that newer version of automake required
newer version of autoconf, which was nowhere near compatible.


regards,
junichi

[Eric Dorland]

Post by Junichi Uekawa
On Sun, 9 Jun 2002 14:15:59 -0400

Post by Eric Dorland

Post by Junichi Uekawa
Hmm.. it's not an alternative if it is not compatible.
It's like bison and yacc, gpc and gcc.

Well to some degree they are compatible. I think a better analogy
would be the various vi clones. They all sort of do the same things,
but they are not necessarily compatible.

I had an impression that newer version of automake required
newer version of autoconf, which was nowhere near compatible.

Alright, the newer versions of automake are not completely backwards
compatible. But the automake alternative would be more of a
convenience, like x-terminal-emulator or x-window-manager.
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Joseph Carter]

Post by Junichi Uekawa

Post by Eric Dorland

Post by Junichi Uekawa
Hmm.. it's not an alternative if it is not compatible.
It's like bison and yacc, gpc and gcc.

Well to some degree they are compatible. I think a better analogy
would be the various vi clones. They all sort of do the same things,
but they are not necessarily compatible.

I had an impression that newer version of automake required
newer version of autoconf, which was nowhere near compatible.

It's compatibile for most things. There are a few thou-shalt-nots which
cause the new version to be broken, but they're easily fixed in almost all
cases. They just require someone to actually do the fixing.
--
Joseph Carter <***@bluecherry.net> I swallowed your goldfish

* bma_home gropes you
<bma_home> "oups, wrong channel"
<bma_home> </acf>
<cerb> quit groping me
<doogie> you know you like it.
<bma_home> actually, it was "grope me baby"
<gecko-> touch my son and you die, bma ;)
<doogie> gecko-: but your wife is ok?

[Junichi Uekawa]

On Sun, 9 Jun 2002 22:47:11 -0700

Post by Joseph Carter

Post by Junichi Uekawa
I had an impression that newer version of automake required
newer version of autoconf, which was nowhere near compatible.

It's compatibile for most things. There are a few thou-shalt-nots which
cause the new version to be broken, but they're easily fixed in almost all
cases. They just require someone to actually do the fixing.

"Compatible for most things" and "it can be fixed up manually"
is not good enough :P

Really, a real solution would be to fixing things which build-depend on
"automake" to depend on "automake1.6" or "automake1.4" or whatever.

Not dumping automake1.6 to be "automake".

a) Dumping automake1.6 to be automake will require:

1. autobuilders (or me) noticing the problem
2. autobuilders (or me) filing bugs on individual packages
3. maintainers, or QA people (or me) fixing and uploading the package


b) Changing the individual packages to build-depend on automake1.6 or
automake1.4 will require:

1. maintainers, or QA people (or you??) fixing and uploading the package


When "automake" is pulled away, packages which still depend
upon automake should be obvious in b, while it won't be obvious
at all in a.

a. is a more convoluted way of fixing the problem at hand.
b. is better in that it costs less for Debian Project as a whole, in total.



Note that most packages won't be autobuilt unless some crazy
fanatic starts rebuilding the whole archive for the fun of it.
Which makes solution a less attractive.


regards,
junichi

[Eric Dorland]

Post by Junichi Uekawa
On Sun, 9 Jun 2002 22:47:11 -0700

Post by Joseph Carter

Post by Junichi Uekawa
I had an impression that newer version of automake required
newer version of autoconf, which was nowhere near compatible.

It's compatibile for most things. There are a few thou-shalt-nots which
cause the new version to be broken, but they're easily fixed in almost all
cases. They just require someone to actually do the fixing.

"Compatible for most things" and "it can be fixed up manually"
is not good enough :P
Really, a real solution would be to fixing things which build-depend on
"automake" to depend on "automake1.6" or "automake1.4" or whatever.
Not dumping automake1.6 to be "automake".

I'm not suggesting that at all. I'm just saying that /usr/bin/automake
should be an alternative provided by the various automake
packages. The automake 1.4 package would have the highest priority for
now for the autobuilders.

Post by Junichi Uekawa
1. autobuilders (or me) noticing the problem
2. autobuilders (or me) filing bugs on individual packages
3. maintainers, or QA people (or me) fixing and uploading the package

Again, i'm not suggesting this.

Post by Junichi Uekawa
b) Changing the individual packages to build-depend on automake1.6 or
1. maintainers, or QA people (or you??) fixing and uploading the package
When "automake" is pulled away, packages which still depend
upon automake should be obvious in b, while it won't be obvious
at all in a.
a. is a more convoluted way of fixing the problem at hand.
b. is better in that it costs less for Debian Project as a whole, in total.

I agree, a. is the better solution.

Post by Junichi Uekawa
Note that most packages won't be autobuilt unless some crazy
fanatic starts rebuilding the whole archive for the fun of it.
Which makes solution a less attractive.
regards,
junichi

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Junichi Uekawa]

On Mon, 10 Jun 2002 02:21:32 -0400

Post by Eric Dorland

Post by Junichi Uekawa
Really, a real solution would be to fixing things which build-depend on
"automake" to depend on "automake1.6" or "automake1.4" or whatever.
Not dumping automake1.6 to be "automake".

I'm not suggesting that at all. I'm just saying that /usr/bin/automake
should be an alternative provided by the various automake
packages. The automake 1.4 package would have the highest priority for
now for the autobuilders.

"alternative" is not a good idea, because someone might try building
packages with automake 1.6 when it is known to work only with
automake 1.4

regards,
junichi

[Denis Barbier]

On Mon, Jun 10, 2002 at 04:12:55PM +0900, Junichi Uekawa wrote:
[...]

Post by Junichi Uekawa
"alternative" is not a good idea, because someone might try building
packages with automake 1.6 when it is known to work only with
automake 1.4

In which case it should build-depend upon automake1.4.

Denis

[Junichi Uekawa]

On Mon, 10 Jun 2002 10:32:06 +0200

Post by Denis Barbier
[...]

Post by Junichi Uekawa
"alternative" is not a good idea, because someone might try building
packages with automake 1.6 when it is known to work only with
automake 1.4

In which case it should build-depend upon automake1.4.

The only problem being that no package actually does that currently,
so the point is moot.


regards,
junichi

[Joseph Carter]

Post by Denis Barbier
[...]

Post by Junichi Uekawa
"alternative" is not a good idea, because someone might try building
packages with automake 1.6 when it is known to work only with
automake 1.4

In which case it should build-depend upon automake1.4.

Or be fixed. Once again, and for the twentieth time, there are people who
have offered to go through basically the entire distribution and fix any
package we find which doesn't work with automake1.6...

[Junichi Uekawa]

On Tue, 11 Jun 2002 01:31:31 -0700

Post by Joseph Carter

Post by Denis Barbier
In which case it should build-depend upon automake1.4.

Or be fixed. Once again, and for the twentieth time, there are people who
have offered to go through basically the entire distribution and fix any
package we find which doesn't work with automake1.6...

Then, please "the people", go through the packages which
depend on automake, and fix them to depend on automake1.5/automake1.6


regards,
junichi

[Eric Dorland]

Post by Junichi Uekawa
On Tue, 11 Jun 2002 01:31:31 -0700

Post by Joseph Carter

Post by Denis Barbier
In which case it should build-depend upon automake1.4.

Or be fixed. Once again, and for the twentieth time, there are people who
have offered to go through basically the entire distribution and fix any
package we find which doesn't work with automake1.6...

Then, please "the people", go through the packages which
depend on automake, and fix them to depend on automake1.5/automake1.6

But wait for automake1.6 to make it into main. You can get them from
http://people.debian.org/~eric/automake/.

Post by Junichi Uekawa
regards,
junichi

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Joseph Carter]

Post by Junichi Uekawa

Post by Joseph Carter
It's compatibile for most things. There are a few thou-shalt-nots which
cause the new version to be broken, but they're easily fixed in almost all
cases. They just require someone to actually do the fixing.

"Compatible for most things" and "it can be fixed up manually"
is not good enough :P

Well we have this little problem you see...

We can't control upstream. They fucked up, badly. But we can't undo
their fuckup for them, and they seem uninclined to do it. Best we can do
is fix things in Debian so that they work, regardless of which version of
automake you use on them.

Post by Junichi Uekawa
Really, a real solution would be to fixing things which build-depend on
"automake" to depend on "automake1.6" or "automake1.4" or whatever.

I don't see the problem with an alternative of 20 vs 40 for 1.6 and 1.4
respectively. If you have automake1.6 only, it will probably work as
automake if upstream has been taking care of their software. If not,
well, install 1.4!

I think that within Debian we should pick one and stick to it. Since 1.5
is now required for several things and anything which doesn't work with
1.5+ is regarded upstream as a bug, it's unreasonable for us to make that
standard be 1.4.. But I don't think we can remove 1.4 either. No matter
what we do inside Debian, the outside world will continue to do what it
pleases. At least one project I know of does not work with 1.5+ and its
author says hell will freeze before he updates to the new versions, since
he considers them profoundly broken.

As usual, Debian gets stuck cleaning up the mess.

Post by Junichi Uekawa
Not dumping automake1.6 to be "automake".
1. autobuilders (or me) noticing the problem
2. autobuilders (or me) filing bugs on individual packages
3. maintainers, or QA people (or me) fixing and uploading the package

I have already proposed the solution to this problem. It involves:

1. Building a list of all packages in Debian which do not work with
current versions of autoconf/automake, outside the BTS.
2. Interested developers fixing these packages to work with the current
versions of autoconf/automake.
3. Package maintainers or those interested developers uploading new
versions of the packages with patches applied.


All of this should be done well in advance of any alternatives,
autobuilder processing, or filing of bug reports. But it needs doing
because at some point, when someone says you need automake, it will be
expected that tey mean 1.6 or some later version. We cannot bury our
heads in the sand on this one.

Post by Junichi Uekawa
b) Changing the individual packages to build-depend on automake1.6 or
1. maintainers, or QA people (or you??) fixing and uploading the package

This ignores the fact that we will need to have, essentially forever, two
different and almost compatible versions of the same package. If a
package does not work with 1.6, it needs fixing. That is all - it is a
bug that we should treat like any other.

However, given that this bug is completely upstream's fault, and given
that there are developers willing to go through the entire distribution
and fix these bugs now, that is precisely the correct solution.

Post by Junichi Uekawa
When "automake" is pulled away, packages which still depend
upon automake should be obvious in b, while it won't be obvious
at all in a.
a. is a more convoluted way of fixing the problem at hand.
b. is better in that it costs less for Debian Project as a whole, in total.

Personally, I don't want to NEED automake1.4 in six months. And in about
a year, I expect no excuse to even have it. Times change, software gets
updated. Sometimes you like how it was updated, sometimes you don't. The
rest of the world is getting on with life.

Using your proposed non-solution, I can virtually guarantee that four
years from now, when I finally get my fresh from the press Sarge CD set, I
will need both a current and a long-since obsolete version of the same
program because people will have concluded the build-depends on the old
vs. new automake to be sufficient.

We can fix that in a few weeks' time, largely without impacting the
distribution at all until after the work has been done. Should we ignore
this opportunity to address the problem before it ever becomes one?

Post by Junichi Uekawa
Note that most packages won't be autobuilt unless some crazy
fanatic starts rebuilding the whole archive for the fun of it.
Which makes solution a less attractive.

I've proposed that crazy fanatics begin doing so now, using automake1.6 as
automake, to find out what breaks. This reduces the problem set to just
those things which actually have a problem, clearly. There should not be
many such packages, and even those of us on modems can make short work of
these few things which break.

[Anthony Towns]

Post by Joseph Carter

Post by Junichi Uekawa

Post by Joseph Carter
It's compatibile for most things. There are a few thou-shalt-nots which
cause the new version to be broken, but they're easily fixed in almost all
cases. They just require someone to actually do the fixing.

"Compatible for most things" and "it can be fixed up manually"
is not good enough :P

Well we have this little problem you see...
We can't control upstream. They fucked up, badly.

But we can control what we do, and we are meant to ensure that upstream's
fuckups don't affect either us or our users, where such a thing is
possible.

The latter is clearly possible here: avoid making automake1.5 or
automake1.6 be what you get when you say "apt-get install automake", and
ensure that when you've got automake 1.4 installed, you don't accidently
get a different version when you expect automake 1.4.

That's all that *matters*, everything else -- like making it obvious which
automake should be installed for users to develop with, or getting all
our packages to build with a single version of automake -- is just glitz.

Cheers,
aj

[Andrew Suffield]

Post by Scott James Remnant

Post by Jordi Mallach
How handle automake now that Woody is frozen is another question. Will
automake get back to being the latest version? I guess it's the right
moment to break things in unstable.

If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

FWIW, all the Makefile.am's I have ever written (created mostly with
automake 1.4), many of which are quite sophisticated, have worked fine
with automake 1.5 (or at least as well as they did with 1.4). Most of
the problems I've seen stem from attempts at "workarounds" for things
which automake blatantly does not support (like building source files
which are located in directories other than the one where Makefile.am
is located).

Haven't tried the versions which haven't made it into debian yet,
though.

[Roger Leigh]

Post by Andrew Suffield

Post by Scott James Remnant
If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

FWIW, all the Makefile.am's I have ever written (created mostly with
automake 1.4), many of which are quite sophisticated, have worked fine
with automake 1.5 (or at least as well as they did with 1.4). Most of
the problems I've seen stem from attempts at "workarounds" for things
which automake blatantly does not support (like building source files
which are located in directories other than the one where Makefile.am
is located).

I see the same thing too. My Makefile.ams work fine with 1.4x and 1.5. I
did have to remove some ugly hacks that broke automake 1.5, but since then
they work with either.

Post by Andrew Suffield
Haven't tried the versions which haven't made it into debian yet,
though.

They work fine with 1.6x too. Once you use 1.5/1.6 features, 1.4
obviously breaks, but I have never seen unsolvable backwards compatibility
problems.

[Jordi Mallach]

Post by Scott James Remnant

Post by Jordi Mallach
What's up with the automake packages?

The initial problem at least is that "compatible" is not a word most
people choose to describe automake 1.4, 1.5 and 1.6.

Well, yes... I know what happened when the automake package switched to
1.5, but I guess we can't stick with automake 1.4 forever...

Post by Scott James Remnant
If an application was written to use automake 1.4 or before, automake
1.4 is the latest version of automake you can use to generate the
Makefile.ins for it. This is the majority of applications, and will
probably remain so for quite some time.

That isn't true for all cases. Just to put an example, nano does well
with both 1.4 and 1.5.

My concern, in any case isn't incompatibility problems in automake
releases. If we need to use an "automake1.6" package, I'd welcome it
too. The problem is the bad state of these pacakges. Even 1.4 isn't up
to the last release (1.4-p5, #127347).

People *need* automake1.6, it's blocking other packages from being
updated.

I could create such source package, but I don't know if assigning it to
Kevin would be nice...

Jordi

[Steve M. Robbins]

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]

The reason that it is the other way around was mainly to avoid lots of
breakage during the woody freeze. Since woody is now frozen, we ought
to be able to reverse the practice now.

Post by Eric Dorland
Kevin (the current automake maintainer) seems unresponsive. Should I
NMU them for now, or actually take them over?

You might want to give Kevin a reasonable amount of time to respond.
But it would be really nice to have automake maintained in a timely
fashion, whoever does it.

Regards,
-Steve

[Junichi Uekawa]

Post by Steve M. Robbins

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]

My preference would be that package automake be a virtual package
that is provided and conflicted by automakex.x.

These automake versions provide the interface expected by the user
as an automake program, but are not really completely compatible.

It's better than the current situation of having random packages
depending on "automake" and being broken with the latest version
of automake.


regards,
junichi

[Eric Dorland]

Post by Junichi Uekawa

Post by Steve M. Robbins

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]

My preference would be that package automake be a virtual package
that is provided and conflicted by automakex.x.

Well only automake 1.4 and 1.5 conflict, 1.6 doesn't conflict with
either of them.

Post by Junichi Uekawa
These automake versions provide the interface expected by the user
as an automake program, but are not really completely compatible.
It's better than the current situation of having random packages
depending on "automake" and being broken with the latest version
of automake.

I agree... people should have a versioned depend on automake.

Post by Junichi Uekawa
regards,
junichi

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Eric Dorland]

Hey Steve :)

Post by Steve M. Robbins

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]
The reason that it is the other way around was mainly to avoid lots of
breakage during the woody freeze. Since woody is now frozen, we ought
to be able to reverse the practice now.

That's a nice idea, but it means that things that depend on "automake"
could break the next time a new version of automake is released. I
think the versioned binaries approach automake is taking, a package
called automake1.X makes more sense. It would be nice to rename the
automake package automake1.4 though. Would this piss people off who
depend on automake? Or should I make an empty automake package that
depends on automake1.4 for now, and later on depend on automake1.6
when people have changed dependencies properly.

Post by Steve M. Robbins

Post by Eric Dorland
Kevin (the current automake maintainer) seems unresponsive. Should I
NMU them for now, or actually take them over?

You might want to give Kevin a reasonable amount of time to respond.
But it would be really nice to have automake maintained in a timely
fashion, whoever does it.

According to other people he has already not answered email queries
for a number of weeks. But yes, I am reluctant to
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Anthony Towns]

Post by Eric Dorland

Post by Steve M. Robbins
If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]
The reason that it is the other way around was mainly to avoid lots of
breakage during the woody freeze. Since woody is now frozen, we ought
to be able to reverse the practice now.

That's a nice idea, but it means that things that depend on "automake"
could break the next time a new version of automake is released.

Right, which means things shouldn't depend on "automake". Unfortunately we
weren't expecting upstream to randomly break compatability like that, so
whole swathes of packages _did_ depend on automake. Making "automake.deb"
be automake1.4 worked around this for us since the buildds will always
choose a real package named "automake" in place of the virtual package
provided by automake1.5. You'll probably want to be careful not to break
this for a while, which means not having "automake.deb" be version 1.5
or 1.6.

One possibility is to make "automake1.4.deb" be the only package that
provides "automake", and then adjust the conflicts between automake
1.4 and automake 1.5 to ensure they don't get installed together if it
breaks things. If we've got three versions of automake, which aren't
particularly compatible, and which are all used widely, there's probably
not that much value in trying to provide a "canonical" automake.deb.

There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``BAM! Science triumphs again!''
-- Loading Image...

[Eric Dorland]

Post by Anthony Towns

Post by Eric Dorland

Post by Steve M. Robbins
If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]
The reason that it is the other way around was mainly to avoid lots of
breakage during the woody freeze. Since woody is now frozen, we ought
to be able to reverse the practice now.

That's a nice idea, but it means that things that depend on "automake"
could break the next time a new version of automake is released.

Right, which means things shouldn't depend on "automake". Unfortunately we
weren't expecting upstream to randomly break compatability like that, so
whole swathes of packages _did_ depend on automake. Making "automake.deb"
be automake1.4 worked around this for us since the buildds will always
choose a real package named "automake" in place of the virtual package
provided by automake1.5. You'll probably want to be careful not to break
this for a while, which means not having "automake.deb" be version 1.5
or 1.6.

Yes, I totally agree.

Post by Anthony Towns
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", and then adjust the conflicts between automake
1.4 and automake 1.5 to ensure they don't get installed together if it
breaks things. If we've got three versions of automake, which aren't
particularly compatible, and which are all used widely, there's probably
not that much value in trying to provide a "canonical" automake.deb.

Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily
automake1.4. It is possible to write Makefile.am's that are portable
across all the current versions. It would be nice if packages which
depend on automake could depend on the right version (eg. automake1.4
or automake1.5) if it really does depend on a specific version.

Post by Anthony Towns
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Yes, but it might be nice for someone to do apt-get install automake
and get a nice version of automake installed. I realize that's
somewhat low priority, but it would still be nice :)

Post by Anthony Towns
Cheers,
aj

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Joseph Carter]

Post by Eric Dorland

Post by Anthony Towns
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", and then adjust the conflicts between automake
1.4 and automake 1.5 to ensure they don't get installed together if it
breaks things. If we've got three versions of automake, which aren't
particularly compatible, and which are all used widely, there's probably
not that much value in trying to provide a "canonical" automake.deb.

Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily
automake1.4. It is possible to write Makefile.am's that are portable
across all the current versions. It would be nice if packages which
depend on automake could depend on the right version (eg. automake1.4
or automake1.5) if it really does depend on a specific version.

Any package I use (and therefore can test) which does not build with
automake 1.5 or 1.6 in sid, I will be happy to download, fix, and send
patches both to the Debian BTS and upstream if possible. This goes for
autoconf 2.5+ as well.

If others are willing to do the same, I think it's a safe bet that we can
move to 1.6 relatively easily. I say relatively because some of the
things that are no longer acceptable to the autoconf/automake people were
needed to get certain unprovided features in a sane manner. Programs
which do anything like this are rare enough though that most people won't
have any trouble. The exceptions may take some texinfo reading or some
person who is basically very comfortable with auto* voodoo, but I'm
convinced we could make short work of it.

Post by Eric Dorland

Post by Anthony Towns
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Yes, but it might be nice for someone to do apt-get install automake
and get a nice version of automake installed. I realize that's
somewhat low priority, but it would still be nice :)

First thing that needs to happen in order to get that is for someone with
bandwidth and CPU to burn to set up an autobuilder and try building
anything that needs automake with 1.5/1.6 and generate a list of failure
cases. Once we have that, this whole process gets simpler.

I don't have the bandwidth (56k shared by 5 machines just isn't at all
sufficient!) but I have CPU enough to go about fixing the failure cases
once they're known.

[Eric Dorland]

Post by Joseph Carter

Post by Eric Dorland

Post by Anthony Towns
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", and then adjust the conflicts between automake
1.4 and automake 1.5 to ensure they don't get installed together if it
breaks things. If we've got three versions of automake, which aren't
particularly compatible, and which are all used widely, there's probably
not that much value in trying to provide a "canonical" automake.deb.

Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily
automake1.4. It is possible to write Makefile.am's that are portable
across all the current versions. It would be nice if packages which
depend on automake could depend on the right version (eg. automake1.4
or automake1.5) if it really does depend on a specific version.

Any package I use (and therefore can test) which does not build with
automake 1.5 or 1.6 in sid, I will be happy to download, fix, and send
patches both to the Debian BTS and upstream if possible. This goes for
autoconf 2.5+ as well.

That would be great.

Post by Joseph Carter
If others are willing to do the same, I think it's a safe bet that we can
move to 1.6 relatively easily. I say relatively because some of the
things that are no longer acceptable to the autoconf/automake people were
needed to get certain unprovided features in a sane manner. Programs
which do anything like this are rare enough though that most people won't
have any trouble. The exceptions may take some texinfo reading or some
person who is basically very comfortable with auto* voodoo, but I'm
convinced we could make short work of it.

Again, this would be great, but rallying the troops to do this might
be hard.

Post by Joseph Carter

Post by Eric Dorland

Post by Anthony Towns
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Yes, but it might be nice for someone to do apt-get install automake
and get a nice version of automake installed. I realize that's
somewhat low priority, but it would still be nice :)

First thing that needs to happen in order to get that is for someone with
bandwidth and CPU to burn to set up an autobuilder and try building
anything that needs automake with 1.5/1.6 and generate a list of failure
cases. Once we have that, this whole process gets simpler.

I certainly have enough bandwidth, but how would i find all the
packages that build-depend on automake?

Post by Joseph Carter
I don't have the bandwidth (56k shared by 5 machines just isn't at all
sufficient!) but I have CPU enough to go about fixing the failure cases
once they're known.

--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Denis Barbier]

[...]

Post by Eric Dorland

Post by Joseph Carter
If others are willing to do the same, I think it's a safe bet that we can
move to 1.6 relatively easily. I say relatively because some of the
things that are no longer acceptable to the autoconf/automake people were
needed to get certain unprovided features in a sane manner. Programs
which do anything like this are rare enough though that most people won't
have any trouble. The exceptions may take some texinfo reading or some
person who is basically very comfortable with auto* voodoo, but I'm
convinced we could make short work of it.

Again, this would be great, but rallying the troops to do this might
be hard.

Count me too.

[...]

Post by Eric Dorland
I certainly have enough bandwidth, but how would i find all the
packages that build-depend on automake?

Neil Spring did this job months ago, see
http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00646.html
You might also have a look at the whole thread
http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00492.html

Convince Debian developers to read
/usr/share/doc/autotools-dev/README.Debian.gz
and avoid build dependencies against auto* tools would also be nice.

Denis

[Joseph Carter]

Post by Eric Dorland

Post by Joseph Carter
If others are willing to do the same, I think it's a safe bet that we can
move to 1.6 relatively easily. I say relatively because some of the
things that are no longer acceptable to the autoconf/automake people were
needed to get certain unprovided features in a sane manner. Programs
which do anything like this are rare enough though that most people won't
have any trouble. The exceptions may take some texinfo reading or some
person who is basically very comfortable with auto* voodoo, but I'm
convinced we could make short work of it.

Again, this would be great, but rallying the troops to do this might
be hard.

If three more people step up to do this, and one or two people step up to
do all the autobuilding, we can make short work of the entire contents of
sid, I suspect. And given authority to generally abuse power and NMU
packages with purely the auto* fixes if the maintainer doesn't do so in a
reasonable timeframe, I suspect it won't be too hard.

Of course, people will scream about the abuse of power thing, but it is my
experience that nothing worth while gets done in this project without
_someone_ complaininag about it. ;)

Post by Eric Dorland

Post by Joseph Carter
First thing that needs to happen in order to get that is for someone with
bandwidth and CPU to burn to set up an autobuilder and try building
anything that needs automake with 1.5/1.6 and generate a list of failure
cases. Once we have that, this whole process gets simpler.

I certainly have enough bandwidth, but how would i find all the
packages that build-depend on automake?

You might be able to get this in some automated fashion from auric, or
more importantly one of the existing buildd operators may be able to help.
I seem to recall they happen to have such information tallied from a time
before build-depends.

[Junichi Uekawa]

Post by Joseph Carter
If three more people step up to do this, and one or two people step up to
do all the autobuilding, we can make short work of the entire contents of
sid, I suspect. And given authority to generally abuse power and NMU
packages with purely the auto* fixes if the maintainer doesn't do so in a
reasonable timeframe, I suspect it won't be too hard.

I have a very large backlog of build failures listed in
BTS already, which I myself cannot really process within a
reasonable timeframe.

I don't think it's feasible to get something like that done.

I think we already have some unfixed build failures caused by
the new libtool.



regards,
junichi

[Joseph Carter]

Post by Junichi Uekawa

Post by Joseph Carter
If three more people step up to do this, and one or two people step up to
do all the autobuilding, we can make short work of the entire contents of
sid, I suspect. And given authority to generally abuse power and NMU
packages with purely the auto* fixes if the maintainer doesn't do so in a
reasonable timeframe, I suspect it won't be too hard.

I have a very large backlog of build failures listed in
BTS already, which I myself cannot really process within a
reasonable timeframe.
I don't think it's feasible to get something like that done.

I'm not talking about FTBFS bugs here, I'm talking about building
everything which uses auto* against current versions and noting the
failures in a central non-BTS location for people who have both time and
experience to fix them as part of a project-wide transition. Once this
has been done, patches which fix it may be sent both upstream and to the
Debian BTS.

I'm not advocating maintainers do this themselves right away, since I'm
advocating that this be done quickly and I know it won't happen if we
leave it to the individual maintainers to fix as they will or can. (I
happen to know a couple developers off hand who simply don't grok auto* at
all. At least one of them is an accomplished C/C++ programmer, but
doesn't understand autoconf well and automake even less. I'm sure there
are others. This is no different than me really - to this day I still
can barely read, much less sanely write, anything at all in perl.

Now, if in a month or so after this is done, if these patches are not
applied, I advocate an NMU because we're talking about a project-wide
transition here and we can't expect this to be held up forever by a
maintainer who doesn't want to make an upload to apply the patch. This is
where I see the potential for complaints.

Post by Junichi Uekawa
I think we already have some unfixed build failures caused by
the new libtool.

I am not certain as I am not aware of all of the issues, but many of these
problems could likely get fixed automagically by people porting packages
to current autothings.

[Richard Braakman]

Post by Joseph Carter
Of course, people will scream about the abuse of power thing, but it is my
experience that nothing worth while gets done in this project without
_someone_ complaininag about it. ;)

What you describe is pretty much how we dealt with the libc5->libc6
transition. It should still be possible. If it isn't, then we have
a significant problem of fossilization.

But remember rule #1 of NMU's:
Get it right. All else can be forgiven.

Richard Braakman

[Anthony Towns]

Post by Eric Dorland

Post by Anthony Towns
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", [...]

Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily
automake1.4. It is possible to write Makefile.am's that are portable
across all the current versions.

Does that also mean they'll be portable to automake1.7, or is it just
a coincidence that upstream haven't made incompatible changes for those
particular features? (Bitter? Who, me?) I haven't looked at automake1.6,
but if it doesn't conflict: with automake1.4, then presumably it doesn't
provide /usr/bin/automake?

Post by Eric Dorland

Post by Anthony Towns
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Yes, but it might be nice for someone to do apt-get install automake
and get a nice version of automake installed. I realize that's
somewhat low priority, but it would still be nice :)

All you need for that is for "automake" to be provided by just one
package. But it's more important for the buildds to be able to do
"apt-get install automake" and have the version that satisfies the
build-dependencies correctly get installed.

Cheers,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif

[Eric Dorland]

Post by Anthony Towns

Post by Eric Dorland

Post by Anthony Towns
One possibility is to make "automake1.4.deb" be the only package that
provides "automake", [...]

Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily
automake1.4. It is possible to write Makefile.am's that are portable
across all the current versions.

Does that also mean they'll be portable to automake1.7, or is it just
a coincidence that upstream haven't made incompatible changes for those
particular features? (Bitter? Who, me?) I haven't looked at automake1.6,
but if it doesn't conflict: with automake1.4, then presumably it doesn't
provide /usr/bin/automake?

It is possible to write Makefile.am's that are portable across all the
current versions of automake. Quoting from the automake manual:

"New Automake releases usually include bug fixes and new
features. Unfortunately they may also introduce new bugs and
incompatibilities. This make four reasons why a package may require a
particular Automake version."

Which doesn't seem to say drastic things about breaking backwards
compatibility every release. Automake 1.6 provides a binary called
automake-1.6, because it is not backwards compatible with every
undocumented feature that worked in previous versions.

Post by Anthony Towns

Post by Eric Dorland

Post by Anthony Towns
There's probably no need for a dummy package -- they're only really
useful when you're splitting a package.

Yes, but it might be nice for someone to do apt-get install automake
and get a nice version of automake installed. I realize that's
somewhat low priority, but it would still be nice :)

All you need for that is for "automake" to be provided by just one
package. But it's more important for the buildds to be able to do
"apt-get install automake" and have the version that satisfies the
build-dependencies correctly get installed.

Right, but right some packages depend on automake, when they really
mean automake1.4. If we renamed the current automake package
automake1.4, then have a dummy package that depends on automake1.4
until all the dependencies are fixed. Then the automake dummy package
can depend on the latest automake1.X package.

I understand what you mean by having only one package provide
'automake', and it would solve the problem. But its a bit of
deception, since all the automake1.X packages provide the ability to
'automake' style things.
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Matt Zimmerman]

Post by Eric Dorland
Yes, but that seems like a bit of an inelegant solution, since it is
possible for a package to want any automake, not necessarily automake1.4.
It is possible to write Makefile.am's that are portable across all the
current versions. It would be nice if packages which depend on automake
could depend on the right version (eg. automake1.4 or automake1.5) if it
really does depend on a specific version.

Even if someone could do this, it would probably not be useful for
Debian, since the maintainer would want to ensure that the package was built
consistently everywhere, with the same version of automake.

[Andreas Metzler]

Post by Steve M. Robbins

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]

[...]

This is probably a silly question, but somebody has to ask it:
Is really 1.5 needed, are there (more than a couple) packages that
work with 1.5 but don't with 1.6?
cu andreas

[Eric Dorland]

Post by Andreas Metzler

Post by Steve M. Robbins

Post by Eric Dorland
What do people think? If there's no serious objections, I'll upload
automake1.6 and start fixing 1.4 and 1.5 once its uploaded.

If feasible, my preference would be that the package "automake"
contains the latest version (i.e. 1.6). The older version could be
stuck in "automake1.4", if need be. [I wonder whether 1.5 is even
needed at this point.]

[...]
Is really 1.5 needed, are there (more than a couple) packages that
work with 1.5 but don't with 1.6?

It's not a silly question at all. My impression is that 1.5 and 1.6
are basically compatible, and are certainly more compatible then 1.4
and 1.5. The reason we *might* want to keep 1.5 around is that it
still works with autoconf 2.13, whereas 1.6 needs autoconf 2.52 or
greater.
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Joseph Carter]

Post by Eric Dorland

Post by Andreas Metzler
Is really 1.5 needed, are there (more than a couple) packages that
work with 1.5 but don't with 1.6?

It's not a silly question at all. My impression is that 1.5 and 1.6
are basically compatible, and are certainly more compatible then 1.4
and 1.5. The reason we *might* want to keep 1.5 around is that it
still works with autoconf 2.13, whereas 1.6 needs autoconf 2.52 or
greater.

Nuke 1.5, fix the packages to work with both autoconf 2.50 and automake
1.6. Call it good.

[Eric Dorland]

Post by Joseph Carter

Post by Eric Dorland

Post by Andreas Metzler
Is really 1.5 needed, are there (more than a couple) packages that
work with 1.5 but don't with 1.6?

It's not a silly question at all. My impression is that 1.5 and 1.6
are basically compatible, and are certainly more compatible then 1.4
and 1.5. The reason we *might* want to keep 1.5 around is that it
still works with autoconf 2.13, whereas 1.6 needs autoconf 2.52 or
greater.

Nuke 1.5, fix the packages to work with both autoconf 2.50 and automake
1.6. Call it good.

I agree that within debian it would desirable to do that, but some
users might be peeved they can't use automake 1.5 anymore...
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------

[Joseph Carter]

Post by Eric Dorland

Post by Joseph Carter

Post by Eric Dorland
are basically compatible, and are certainly more compatible then 1.4
and 1.5. The reason we *might* want to keep 1.5 around is that it
still works with autoconf 2.13, whereas 1.6 needs autoconf 2.52 or
greater.

Nuke 1.5, fix the packages to work with both autoconf 2.50 and automake
1.6. Call it good.

I agree that within debian it would desirable to do that, but some
users might be peeved they can't use automake 1.5 anymore...

Tough. ;)

Seriously though, automake 1.5 never really caught on because unless you
were using autoconf 2.50+ you were basically asking for trouble. I'd be
more concerned with users who want to use autoconf 1.4 for packages
outside of Debian which don't work with anything later. It's simply
unreasonable for Debian to maintain three seperate versions of automake
for two versions of autoconf until the end of time because someone,
somewhere out there may have a package which requires a non-1.4 automake
setup which doesn't support autoconf 2.50+.

[Eric Dorland]

Post by Joseph Carter

Post by Eric Dorland

Post by Joseph Carter

Post by Eric Dorland
are basically compatible, and are certainly more compatible then 1.4
and 1.5. The reason we *might* want to keep 1.5 around is that it
still works with autoconf 2.13, whereas 1.6 needs autoconf 2.52 or
greater.

Nuke 1.5, fix the packages to work with both autoconf 2.50 and automake
1.6. Call it good.

I agree that within debian it would desirable to do that, but some
users might be peeved they can't use automake 1.5 anymore...

Tough. ;)
Seriously though, automake 1.5 never really caught on because unless you
were using autoconf 2.50+ you were basically asking for trouble. I'd be
more concerned with users who want to use autoconf 1.4 for packages
outside of Debian which don't work with anything later. It's simply
unreasonable for Debian to maintain three seperate versions of automake
for two versions of autoconf until the end of time because someone,
somewhere out there may have a package which requires a non-1.4 automake
setup which doesn't support autoconf 2.50+.

Well I've uploaded automake1.6, so once that gets in we'll see well it
works on packages that depend on 1.5. Let's not make any rash
decisions :)
--
Eric Dorland <***@lords.com>
ICQ: #61138586, Jabber: ***@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------