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 |