1 |
Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted: |
2 |
|
3 |
> On 27/04/12 17:15, Duncan wrote: |
4 |
>> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: |
5 |
>>> Having the package manager interact with an eclass function like |
6 |
>>> epatch_user is ugly, and it's unnecessary since we can pull all of the |
7 |
>>> pieces into the package manager in EAPI 5. |
8 |
>> |
9 |
>> But that doesn't solve the problem of making it globally available, |
10 |
>> since it only applies to packages/eclasses that already call |
11 |
>> epatch_user for EAPIs thru current EAPI-4. |
12 |
>> |
13 |
>> In ordered to make it globally available, it cannot simply be an EAPI-5 |
14 |
>> thing, it must apply to all current ebuilds whether they (or an |
15 |
>> inherited eclass) call epatch_user or not. Which means that conflict |
16 |
>> with the existing epatch_user is unavoidable, since it will either try |
17 |
>> to run twice where it's already called, or it won't run at all where |
18 |
>> it's not. |
19 |
> |
20 |
> According to the source, calling it twice is perfectly safe. |
21 |
|
22 |
That's actually one of the points I've been making, that if we simply |
23 |
force an epatch_user at approximately post_src_prepare, the existing code |
24 |
already deals with multiple calls just fine. |
25 |
|
26 |
The problem appears if we then decide that we're going to do something |
27 |
with eautoreconf immediately thereafter. |
28 |
|
29 |
* if we just call it, we're potentially doing extra work both when the |
30 |
patch didn't require it, and when the ebuild already invoked eautoreconf |
31 |
after doing its own patching. |
32 |
|
33 |
* elif we try to somehow detect that it needs to be run, that's a huge |
34 |
amount of additional complexity we're now talking about adding to what |
35 |
WAS a simple globalization of already tested working code. |
36 |
|
37 |
* elif we try to force developers to call it at some point via repoman |
38 |
check or the like, thus letting them decide, then we're possibly looking |
39 |
at eapi5, and in any case, we just lost the point of the entire exercise, |
40 |
to make it global without forcing a touch of every existing ebuild in the |
41 |
tree that doesn't do it yet. |
42 |
|
43 |
Rock, hard place, with us between them! |
44 |
|
45 |
That's why I proposed up-thread that at least for now we go with the |
46 |
simple option, simply have the PM call epatch_user (either supplying its |
47 |
own internal function or sourcing the eclass to get the existing eclass |
48 |
version), and just punt on the eautoreconf stuff for now. As I said |
49 |
there, based on my experience anyway, that covers the for me at least |
50 |
80-90% of use-cases where the patch isn't complex enough to require an |
51 |
eautoreconf, using code that's already known to be solid and well |
52 |
tested. For the remaining 10-20%, the old solution, copying the ebuild |
53 |
to an overlay and adding the patch calls and any other necessary |
54 |
modifications manually, still works. |
55 |
|
56 |
I'd rather take the "good solution", the well tested code we have now, |
57 |
and apply it globally, yielding the 80-90% reduction in forced personal |
58 |
overlay ebuilds as a result, and continue to deal with the 10-20% than |
59 |
need eautoreconf or other processing manually, now, instead of waiting |
60 |
possibly forever for a "perfect" solution that might or might not ever |
61 |
come, even if in theory it could raise that 80-90% to 99%+. |
62 |
|
63 |
But Zac and a few others believe that what I called the "good" solution |
64 |
will result in a more or less continuous flood of bugs from people who |
65 |
expect epatch_user (or whatever replaces it) to "just work" for that |
66 |
perhaps 10-20% where eautoreconf is required as well, and don't believe |
67 |
it's an acceptable tradeoff. Since they're the devs dealing with the |
68 |
bugs, not me, that's a trump card I can't counter. They win. |
69 |
Unfortunately that means we're stuck waiting for a "perfect" solution |
70 |
that may never come, once again, or at least with an eapi5 solution that |
71 |
even when adopted won't reach global coverage for many many years to |
72 |
come. Oh, well... |
73 |
|
74 |
Unless you're talking about eautoreconf, not epatch_user. Actually, |
75 |
calling eautoreconf extra times should be safe. It'll just take longer, |
76 |
potentially MUCH longer, relative to the current merge time of some |
77 |
affected packages. |
78 |
|
79 |
(There's the question too, of what happens if eautoreconf is called on a |
80 |
non-autotools package. But at a suitably high level, that simply gets |
81 |
lumped in with the general robustness question on the whole approach.) |
82 |
|
83 |
-- |
84 |
Duncan - List replies preferred. No HTML msgs. |
85 |
"Every nonfree program has a lord, a master -- |
86 |
and if you use the program, he is your master." Richard Stallman |