Summary: | media-libs/libmikmod-3.1.11-r4 - WANT_AUTOMAKE is too strict | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Renato Caldas <seventhguardian> |
Component: | New packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | martin |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Renato Caldas
2007-07-27 15:32:58 UTC
(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 |