| 1 |
On Tue, 20 Oct 2015 06:00:15 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
[...] |
| 4 |
> > |
| 5 |
> > First, eclasses shouldn't apply patches on their own but take what |
| 6 |
> > the ebuild tells it to apply: With multiple eclasses applying random |
| 7 |
> > patches on their own, you're already asking for trouble. |
| 8 |
> > Then, ebuild can just send all its patches through the first eclass, |
| 9 |
> > which will call the real eaplly_user. |
| 10 |
> > |
| 11 |
> > Sure, there can be imaginary cases where this would horribly break |
| 12 |
> > or not be so convenient, but do we have a real example ? |
| 13 |
> |
| 14 |
> That is a fair point. I think there are other problems with eclasses |
| 15 |
> exporting phase functions which are far more likely to cause issues |
| 16 |
> than patching at the wrong spot. |
| 17 |
|
| 18 |
Probably, indeed. |
| 19 |
|
| 20 |
> I guess the question is whether I/we/whoever is turning eapply_user |
| 21 |
> into a big issue more to force the general move away from exporting |
| 22 |
> phase functions than because it is a big issue on its own. I do think |
| 23 |
> that is the direction we ought to be moving in, but I would agree that |
| 24 |
> we shouldn't be using eapply_user as a club to try to force people to |
| 25 |
> move that way. If we want to discourage eclass phase function |
| 26 |
> exporting, we should just do that on its own merits. |
| 27 |
|
| 28 |
Heh, going OT, I guess I'd be on the other side: kill the |
| 29 |
autotools-centric default phases and move everything to eclasses' |
| 30 |
exported functions :) |
| 31 |
(or make default phases much more friendly to non-autotools build |
| 32 |
systems, but that'd likely double pms size with useless considerations) |
| 33 |
|
| 34 |
|
| 35 |
> So, perhaps it is a fair question to ask what is the specific harm |
| 36 |
> from allowing it to be a no-op on subsequent calls, other than |
| 37 |
> encouraging a coding practice that could possibly have other unrelated |
| 38 |
> effects? |
| 39 |
|
| 40 |
Yep; I can't see any real harm, but this is probably based on a limited |
| 41 |
view of the big picture. |
| 42 |
However, I do think the practice should be discouraged, but 'let be' in |
| 43 |
specific cases like for eclasses co-existence. Actually, just like any |
| 44 |
other (non breaking) QA issue is handled I think. |
Archives