| 1 |
Hello, |
| 2 |
|
| 3 |
Recently a big bunch of autotools related bugs were filed, of which |
| 4 |
quite a few are quite obvious bugs that need to be fixed, but there are |
| 5 |
a few of the kind that I can't agree with without given technical proof |
| 6 |
it's a real problem. |
| 7 |
|
| 8 |
So one of those is the "changes both autotools source and result" kind, |
| 9 |
as seen from |
| 10 |
https://bugs.gentoo.org/showdependencytree.cgi?id=226305&maxdepth=1&hide_resolved=0 |
| 11 |
|
| 12 |
The short summary of most/all of those is that the ebuilds in question |
| 13 |
are either patching or sed'ing not only Makefile.am and/or |
| 14 |
configure.{in,ac}, but also Makefile.in and/or configure and it is |
| 15 |
claimed that this is a "treatment [that] is usually reserved for a few |
| 16 |
selected system packages that cannot have their autotool scripts |
| 17 |
rebuilt.", with a vague claim that it _could_ cause |
| 18 |
maintainermode-driven rebuild of the autotools results. |
| 19 |
|
| 20 |
In most cases stopping the patching of Makefile.in and/or configure |
| 21 |
involves removing that from the patch AND adding eautoreconf to the |
| 22 |
ebuild. |
| 23 |
|
| 24 |
|
| 25 |
The reason why I'm bringing this up is: |
| 26 |
|
| 27 |
Do we really need to inflict the users with a long eautoreconf step, |
| 28 |
when patching Makefile.in and configure alongisde Makefile.am and |
| 29 |
configure.in is working just fine when done right, by my some years of |
| 30 |
experience doing it once in a while where it's easy to provide a clean |
| 31 |
patch for the autotools results? |
| 32 |
|
| 33 |
|
| 34 |
Some reasoning from my side: |
| 35 |
|
| 36 |
1) maintainer-mode driven rebuild is supposed to only happen if |
| 37 |
a) the package defaults to maintainer mode in its configure.in; and |
| 38 |
b) the autotools source is newer than the result, which can happen if |
| 39 |
you _forget_ (as opposed to doing it, which the bugs are trying to |
| 40 |
remove) to patch all results together with sources or you seriously |
| 41 |
screw up the timestamps |
| 42 |
|
| 43 |
2) eautoreconf means a considerable amount of extra time inflicted on |
| 44 |
all _users_ of that package, without a clear technical reasoning why |
| 45 |
that is really necessary |
| 46 |
|
| 47 |
3) Other distributions happily provide a metric ton length of autotools |
| 48 |
patches and it works just fine, albeit constrained to only package |
| 49 |
maintainers in most cases |
| 50 |
|
| 51 |
|
| 52 |
So I personally request to hold off with "fixing" these bugs without a |
| 53 |
clear reasoning on the extra (every) Gentoo users resources taken, until |
| 54 |
a technically valid reason is given, and I believe the burden of proof |
| 55 |
should be on those that want the eautoreconf calls as to justify the |
| 56 |
extra time and resource requirements involved. |
| 57 |
You as the maintainer of an affected package are free to make your own |
| 58 |
decision on this of course right now. |
| 59 |
|
| 60 |
|
| 61 |
Though if you are hitting the maintainer mode rebuild ("missing --run" |
| 62 |
in build.log without quotes or something), then it's a real bug and you |
| 63 |
could probably just as well fix it by patching the Makefile.in or |
| 64 |
configure that you forgot to patch when you patched Makefile.am or |
| 65 |
configure.{in,ac}. |
| 66 |
|
| 67 |
|
| 68 |
-- |
| 69 |
Mart Raudsepp |
| 70 |
Gentoo Developer |
| 71 |
Mail: leio@g.o |
| 72 |
Weblog: http://planet.gentoo.org/developers/leio |
Archives