Hello, Recently a big bunch of autotools related bugs were filed, of which quite a few are quite obvious bugs that need to be fixed, but there are a few of the kind that I can't agree with without given technical proof it's a real problem.
So one of those is the "changes both autotools source and result" kind, as seen from https://bugs.gentoo.org/showdependencytree.cgi?id=226305&maxdepth=1&hide_resolved=0 The short summary of most/all of those is that the ebuilds in question are either patching or sed'ing not only Makefile.am and/or configure.{in,ac}, but also Makefile.in and/or configure and it is claimed that this is a "treatment [that] is usually reserved for a few selected system packages that cannot have their autotool scripts rebuilt.", with a vague claim that it _could_ cause maintainermode-driven rebuild of the autotools results. In most cases stopping the patching of Makefile.in and/or configure involves removing that from the patch AND adding eautoreconf to the ebuild. The reason why I'm bringing this up is: Do we really need to inflict the users with a long eautoreconf step, when patching Makefile.in and configure alongisde Makefile.am and configure.in is working just fine when done right, by my some years of experience doing it once in a while where it's easy to provide a clean patch for the autotools results? Some reasoning from my side: 1) maintainer-mode driven rebuild is supposed to only happen if a) the package defaults to maintainer mode in its configure.in; and b) the autotools source is newer than the result, which can happen if you _forget_ (as opposed to doing it, which the bugs are trying to remove) to patch all results together with sources or you seriously screw up the timestamps 2) eautoreconf means a considerable amount of extra time inflicted on all _users_ of that package, without a clear technical reasoning why that is really necessary 3) Other distributions happily provide a metric ton length of autotools patches and it works just fine, albeit constrained to only package maintainers in most cases So I personally request to hold off with "fixing" these bugs without a clear reasoning on the extra (every) Gentoo users resources taken, until a technically valid reason is given, and I believe the burden of proof should be on those that want the eautoreconf calls as to justify the extra time and resource requirements involved. You as the maintainer of an affected package are free to make your own decision on this of course right now. Though if you are hitting the maintainer mode rebuild ("missing --run" in build.log without quotes or something), then it's a real bug and you could probably just as well fix it by patching the Makefile.in or configure that you forgot to patch when you patched Makefile.am or configure.{in,ac}. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
