1 |
On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aballier@g.o> wrote: |
2 |
> On Mon, 19 Oct 2015 15:49:06 -0400 |
3 |
> Rich Freeman <rich0@g.o> wrote: |
4 |
> |
5 |
> It's not about correctness vs convenience: eapply_user idempotent |
6 |
> doesn't prevent from doing it correctly. It makes it possible to do it |
7 |
> incorrectly though, just like any turing-complete language actually, but |
8 |
> it is not clear at all what would be the ratio of "incorrect convenient |
9 |
> usage" vs "correct convenient usage": if 99.9% of the tree is fine, |
10 |
> then convenience is clearly worth it instead of changing everything to |
11 |
> accommodate the remaining 0.1%. |
12 |
|
13 |
Sure, but that is the point of correctness vs convenience. The goal |
14 |
of correctness is to make it not possible to do things incorrectly, |
15 |
even if that makes it harder to do things correctly. The goal of |
16 |
convenience is to make it easier to do things correctly, even if it |
17 |
makes it possible to do things incorrectly. It is a tradeoff. |
18 |
|
19 |
> eapply_user dying on second call, defined in PMS, OTOH, prevents |
20 |
> such flexibility and thus raises a lot of design questions that, as seen |
21 |
> here, don't seem to have a clear answer yet and for which it could |
22 |
> indeed be worth refactoring. |
23 |
|
24 |
It has a perfectly clear answer - just don't run eapply_user in eclasses. |
25 |
|
26 |
It isn't a convenient answer, perhaps, but it will always work. |
27 |
|
28 |
Apologies to the rest of the Council if this wasn't on everybody's |
29 |
radar back when we were discussing EAPI6. I thought we were mostly on |
30 |
the same page about taking this sort of approach already. I guess it |
31 |
doesn't hurt to be more explicit and less clever in the wording. I |
32 |
don't think we wanted to outright ban eclass use of eapply_user though |
33 |
- it is still appropriate to use in situations where ebuilds are just |
34 |
wrappers around an eclass. |
35 |
|
36 |
> I can't find an example of where the guideline "apply ebuild |
37 |
> patches before eapply_user" would not be sufficient: After all, |
38 |
> all subsequent phases will also run on user-patched sources and there |
39 |
> are millions of ways to make a patch break a package. |
40 |
|
41 |
How would you apply ebuild patches before eapply_user when you have |
42 |
multiple eclasses all applying patches and all calling eapply_user? |
43 |
|
44 |
Adding another phase may be the cleaner solution. It is a bit late to |
45 |
be talking about that, however, for EAPI6. |
46 |
|
47 |
-- |
48 |
Rich |