1 |
Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: |
2 |
|
3 |
> On 04/26/2012 03:08 PM, Duncan wrote: |
4 |
>> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: |
5 |
>>> Also, don't forget to consider the possibility of interference between |
6 |
>>> FEATURES=userpatch and epatch_user (applying same patches twice). |
7 |
>> |
8 |
>> The existing phaselock-file solution should continue to work there. |
9 |
|
10 |
> Having the package manager interact with an eclass function like |
11 |
> epatch_user is ugly, and it's unnecessary since we can pull all of the |
12 |
> pieces into the package manager in EAPI 5. Any eclasses that currently |
13 |
> call epatch_user can have a conditional like this: |
14 |
> |
15 |
> if has $EAPI 0 1 2 3 4 ; then |
16 |
> epatch_user |
17 |
> else |
18 |
> apply_user_patches_here |
19 |
> fi |
20 |
|
21 |
But that doesn't solve the problem of making it globally available, since |
22 |
it only applies to packages/eclasses that already call epatch_user for |
23 |
EAPIs thru current EAPI-4. |
24 |
|
25 |
In ordered to make it globally available, it cannot simply be an EAPI-5 |
26 |
thing, it must apply to all current ebuilds whether they (or an inherited |
27 |
eclass) call epatch_user or not. Which means that conflict with the |
28 |
existing epatch_user is unavoidable, since it will either try to run |
29 |
twice where it's already called, or it won't run at all where it's not. |
30 |
|
31 |
Tho I guess one solution to that would be to change the name of the |
32 |
patches dir for the new version, calling it /etc/portage/patches2/ or |
33 |
some such. Another solution could be to make the existing epatch_user |
34 |
call a no-op, and force post-src-prepare invocation on EAPIs 1-4. |
35 |
|
36 |
But both of these have problems in that they nullify the work done in |
37 |
existing ebuilds to locate the call correctly, before eautoreconf or |
38 |
whatever. |
39 |
|
40 |
> |
41 |
>>> Overall, the "apply_user_patches_here" approach [1] seems pretty |
42 |
>>> reasonable to me. |
43 |
>>> |
44 |
>>> [1] |
45 |
>>> http://archives.gentoo.org/gentoo-dev/ |
46 |
>> msg_c228be85e0c4e577ad194e6004d59062.xml |
47 |
>> |
48 |
>> With the requirements that if the ebuild never calls it, it's still run |
49 |
>> immediately after source_prepare, thus ensuring that it gets called, |
50 |
>> AND that calling either autoreconf or eautoreconf without calling |
51 |
>> apply-user-patches fit is a repoman-checked error, it looks like it |
52 |
>> should work, agreed. |
53 |
> |
54 |
> I think it might be better to die if it's not called in src_prepare, |
55 |
> like Ciaran originally suggested. This ensures that people don't forget |
56 |
> to call it when they are supposed to. |
57 |
|
58 |
That can work for EAPI-5, but what about existing ebuilds? Remember, the |
59 |
goal is global coverage without forcing an edit to every existing ebuild |
60 |
that doesn't yet call it either directly or via eclass. |
61 |
|
62 |
>> But I'm a bit wary as to the robustness. And without a mechanism to |
63 |
>> apply the patches at a particular point (arguably, post-src-prepare) |
64 |
>> even in the absence of a specific apply-user-patches-here call, we're |
65 |
>> back where we were without a global solution, but if the |
66 |
>> hard-invocation is done, then we're back to either inefficiently |
67 |
>> running eautoreconf twice or forced into doing likely failure-prone |
68 |
>> detection, thus the worry over robustness. |
69 |
> |
70 |
> It's no worse than epatch_user currently is. It's the responsibility of |
71 |
> the person who overrides src_prepare to call eautoreconf or whatever |
72 |
> else when necessary, so the package manager will not have the burden. |
73 |
|
74 |
Except that in ordered to make it global without touching existing |
75 |
ebuilds, the PM MUST shoulder the burden. THAT is where the robustness |
76 |
issues appear. |
77 |
|
78 |
The require-it-in-EAPI-5-plus-only solution will help longer term, but |
79 |
given that many core packages are to remain EAPI-0 for the foreseeable |
80 |
future, that could be a VERY long term indeed. Additionally, it only |
81 |
makes user confusion WORSE, since a user still won't know for sure |
82 |
whether his patches will apply to a particular ebuild without looking. |
83 |
Making it "just work" is the goal, and just doing it for EAPI-5+ is nice, |
84 |
but not really sufficient. |
85 |
|
86 |
-- |
87 |
Duncan - List replies preferred. No HTML msgs. |
88 |
"Every nonfree program has a lord, a master -- |
89 |
and if you use the program, he is your master." Richard Stallman |