1 |
On Tue, 20 Oct 2015 04:57:07 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aballier@g.o> |
5 |
> wrote: |
6 |
> > On Mon, 19 Oct 2015 15:49:06 -0400 |
7 |
> > Rich Freeman <rich0@g.o> wrote: |
8 |
> > |
9 |
> > It's not about correctness vs convenience: eapply_user idempotent |
10 |
> > doesn't prevent from doing it correctly. It makes it possible to do |
11 |
> > it incorrectly though, just like any turing-complete language |
12 |
> > actually, but it is not clear at all what would be the ratio of |
13 |
> > "incorrect convenient usage" vs "correct convenient usage": if |
14 |
> > 99.9% of the tree is fine, then convenience is clearly worth it |
15 |
> > instead of changing everything to accommodate the remaining 0.1%. |
16 |
> |
17 |
> Sure, but that is the point of correctness vs convenience. The goal |
18 |
> of correctness is to make it not possible to do things incorrectly, |
19 |
> even if that makes it harder to do things correctly. The goal of |
20 |
> convenience is to make it easier to do things correctly, even if it |
21 |
> makes it possible to do things incorrectly. It is a tradeoff. |
22 |
|
23 |
|
24 |
Ok, that's what I'd call "forced correctness" :) |
25 |
But again, theory tells you that if you want algorithmically checkable |
26 |
correctness then you have to seriously limit your possibilities, which |
27 |
is why I usually don't even consider this tradeoff :) |
28 |
|
29 |
|
30 |
> > eapply_user dying on second call, defined in PMS, OTOH, prevents |
31 |
> > such flexibility and thus raises a lot of design questions that, as |
32 |
> > seen here, don't seem to have a clear answer yet and for which it |
33 |
> > could indeed be worth refactoring. |
34 |
> |
35 |
> It has a perfectly clear answer - just don't run eapply_user in |
36 |
> eclasses. |
37 |
> |
38 |
> It isn't a convenient answer, perhaps, but it will always work. |
39 |
|
40 |
:) |
41 |
|
42 |
[...] |
43 |
> > I can't find an example of where the guideline "apply ebuild |
44 |
> > patches before eapply_user" would not be sufficient: After all, |
45 |
> > all subsequent phases will also run on user-patched sources and |
46 |
> > there are millions of ways to make a patch break a package. |
47 |
> |
48 |
> How would you apply ebuild patches before eapply_user when you have |
49 |
> multiple eclasses all applying patches and all calling eapply_user? |
50 |
|
51 |
First, eclasses shouldn't apply patches on their own but take what the |
52 |
ebuild tells it to apply: With multiple eclasses applying random |
53 |
patches on their own, you're already asking for trouble. |
54 |
Then, ebuild can just send all its patches through the first eclass, |
55 |
which will call the real eaplly_user. |
56 |
|
57 |
Sure, there can be imaginary cases where this would horribly break or |
58 |
not be so convenient, but do we have a real example ? |
59 |
|
60 |
> Adding another phase may be the cleaner solution. It is a bit late to |
61 |
> be talking about that, however, for EAPI6. |
62 |
|
63 |
probably yes |