This should be the same problem described in bug 186782. Maybe I should have filed a global bug report? Or should I keep individual reports? In any case, here it goes: libmikmod's WANT_AUTOMAKE is 1.5. But I've tested it and it compiled fine under the latest automake. Besides, automake versions should be backwards compatible, and from what I've read 1.6 is the first version requiring >=autoconf-2.52. So I suppose there should really be no need to force WANT_AUTOMAKE to something other than "latest" if it does compile with "latest". In case of libmikmod it does.
(In reply to comment #0) > Besides, automake versions should be backwards compatible, Unfortunately, not entirely true :/ > So I suppose there > should really be no need to force WANT_AUTOMAKE to something other than > "latest" if it does compile with "latest". In case of libmikmod it does. I don't like the "latest" stuff, because it might break if next automake/autoconf release is not 100% compatible; I'd prefer being able to specify a list of versions known to work Generally, I prefer to stick with the autotools version upstream used to generate the scripts. In libmikmod's case, it's automake 1.4 & autoconf 2.13, so the WANT_AUTOMAKE=1.5 just seems weird to me... @others: any thoughts about this ? I'm not an expert of the differences between automake/autoconf versions, so... I dunno what to do here.
(In reply to comment #1) > (In reply to comment #0) > > Besides, automake versions should be backwards compatible, > Unfortunately, not entirely true :/ Sadly you are correct, seen many times they simply fail or even worse output wrong results. > @others: any thoughts about this ? I'm not an expert of the differences between > automake/autoconf versions, so... I dunno what to do here. IMO, this bug is pointless.
(In reply to comment #1) > generate the scripts. In libmikmod's case, it's automake 1.4 & autoconf 2.13, > so the WANT_AUTOMAKE=1.5 just seems weird to me... Weird but apparently working, why should we change it?
(In reply to comment #1) > (In reply to comment #0) > I don't like the "latest" stuff, because it might break if next > automake/autoconf release is not 100% compatible; I'd prefer being able to > specify a list of versions known to work > > Generally, I prefer to stick with the autotools version upstream used to > generate the scripts. In libmikmod's case, it's automake 1.4 & autoconf 2.13, > so the WANT_AUTOMAKE=1.5 just seems weird to me... > IMHO we shouldn't force "slot bloat" when it's not needed. As I said things are _supposed_ to be backward compatible, which means the latest version will work 95% of the time. Only some weird trees may not build, in which case we would use the forcing mechanism. Forcing versions just to be sure is not a good long-term policy IMHO. So unless there IS an actual reason to force automake/autoconf versions I would vote to just remove the WANT* stuff. As the saying: "keep it simple, stupid" :)
Meanwhile there are only 4 other packages in the tree requiring automake-1.5 which presumably many (most?) users will not have installed (htmltidy sdsc-syslog sgml-common libdockapp). This means that many users have installed about 1 MB of automake:1.5 only because of libmikmod. Given that libmikmod works without problems with newer automake versions (I just tested with 1.10.2) and there never was a sign that it won't, do you still think that it is appropriate to force users to install a package which should ideally have been obsoleted since about 7 years, just because libmikmod might _possibly_ break when a new incompatible automake appears? Besides the fact that this potential breakage does not distinguish libmikmod from any other package of the tree, I do not see the danger in omitting the WANT_AUTOMAKE: If really something should break with a future automake, some user will certainly write a bug report, and it would be trivial in such a case to insert again some WANT_AUTOMAKE. So it is not a big deal, but might save many users of unneeded installation of automake-1.5.
Since I'm not the only one that thinks this bug report makes sense, and since the closing reason is basically "I don't care", I'm reopening it.
ok, fixed in -r5
