1 |
On Wed, 21 Oct 2015 01:24:00 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
> Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted: |
5 |
> |
6 |
> > On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman <rich0@g.o> |
7 |
> > wrote: |
8 |
> > |
9 |
> >> So, perhaps it is a fair question to ask what is the specific harm |
10 |
> >> from allowing it to be a no-op on subsequent calls, other than |
11 |
> >> encouraging a coding practice that could possibly have other |
12 |
> >> unrelated effects? |
13 |
> > |
14 |
> > Yep; I can't see any real harm, but this is probably based on a |
15 |
> > limited view of the big picture. |
16 |
> > However, I do think the practice should be discouraged, but 'let |
17 |
> > be' in specific cases like for eclasses co-existence. Actually, |
18 |
> > just like any other (non breaking) QA issue is handled I think. |
19 |
> |
20 |
> Wouldn't the ultimate effect of "let be", assuming the simplest first- |
21 |
> eclass-applies rule, effectively undo the entire purpose of having a |
22 |
> mandatory eapply_user in the first place? |
23 |
> |
24 |
> IOW, now, without some hook, users can't depend on epatch_user. |
25 |
> |
26 |
> Wouldn't "let be" simply define eapply_user as just as undependable, |
27 |
> if not more so, because users couldn't simply pickup patches, dump |
28 |
> them in ${PM_LOCAL_PATCHDIR}, and expect them to actually apply |
29 |
> properly, because the first eapply_user would apply them and then the |
30 |
> patches other eclasses attempt to apply would break, triggering a die. |
31 |
|
32 |
'let be' means that ebuild patches are applied before; whatever you may |
33 |
invent, PM has no way to prevent: |
34 |
|
35 |
src_prepare() { |
36 |
some_eclass_that_calls_eapply_user_exactly_once |
37 |
epatch "something" |
38 |
} |
39 |
|
40 |
what you describe is not fixed by dying on second eapply_user call, and |
41 |
'let be' actually means we have to face it, understand it and handle it |
42 |
properly |
43 |
|
44 |
|
45 |
> And if eapply_user is as undependable, why go thru the whole empty |
46 |
> exercise in the first place? Just leave epatch_user alone, because |
47 |
> after all, users who really want it to be dependable can already |
48 |
> hook-apply it as necessary. |
49 |
|
50 |
|
51 |
'must be called at least once' makes it quite dependable I think |
52 |
|
53 |
|
54 |
> Thus, this really does need worked thru, either somehow forcing the |
55 |
> eapply_user to be applied once, after everything else, ignoring |
56 |
> earlier calls (the new src_prepare2 phase, with the PM running |
57 |
> eapply_user between the two and 2 only doing whatever auto* magic, |
58 |
> etc, needs done), or forcing "exactly once" wording, effectively |
59 |
> forcing eclasses to behave and not call it, which in turn forces the |
60 |
> ebuild to call both the individual eclass functions and eapply_user, |
61 |
> at the appropriate time. |
62 |
> |
63 |
> But thinking about it a bit, what happens if eapply_user is defined |
64 |
> as a PM function/phase that will be called exactly once... between |
65 |
> src_prepare and src_configure? |
66 |
> |
67 |
> Then existing patch functionality can continue to be called by the |
68 |
> eclasses as it is now, perhaps a bit of a mess, but no change so it's |
69 |
> a mess we've generally already adjusted to, eapply_user gets called |
70 |
> as a PM function, and all the auto* and etc magic gets called in |
71 |
> src_configure, just before the normal configure functionality. |
72 |
|
73 |
that's another solution, but src_configure was meant for, heh, |
74 |
configure, and src_prepare was meant for preparing the sources; |
75 |
calling autotools in something else than src_prepare triggers warnings |
76 |
I think. Nothing prevents from adding new phases, but as already said, |
77 |
it's a bit late for eapi6 :/ |
78 |
|
79 |
[...] |
80 |
|
81 |
Alexis. |