Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[Rich Freeman]

On Tue, Oct 20, 2015 at 5:22 AM, Alexis Ballier <aballier@g.o> wrote:
>
> Ok, that's what I'd call "forced correctness" :)
> But again, theory tells you that if you want algorithmically checkable
> correctness then you have to seriously limit your possibilities, which
> is why I usually don't even consider this tradeoff :)
>

I'm not suggesting we're achieving perfection here.  However, I think
that a lot of how we do things encourages lazy ebuild writing.  That
does have a cost in QA, and maintainability.

Now, making it harder to write ebuilds also has a cost in fewer
ebuilds getting written.  So, this is a trade-off.  I do get that.

>
> First, eclasses shouldn't apply patches on their own but take what the
> ebuild tells it to apply: With multiple eclasses applying random
> patches on their own, you're already asking for trouble.
> Then, ebuild can just send all its patches through the first eclass,
> which will call the real eaplly_user.
>
> Sure, there can be imaginary cases where this would horribly break or
> not be so convenient, but do we have a real example ?

That is a fair point.  I think there are other problems with eclasses
exporting phase functions which are far more likely to cause issues
than patching at the wrong spot.

I guess the question is whether I/we/whoever is turning eapply_user
into a big issue more to force the general move away from exporting
phase functions than because it is a big issue on its own.  I do think
that is the direction we ought to be moving in, but I would agree that
we shouldn't be using eapply_user as a club to try to force people to
move that way.  If we want to discourage eclass phase function
exporting, we should just do that on its own merits.

So, perhaps it is a fair question to ask what is the specific harm
from allowing it to be a no-op on subsequent calls, other than
encouraging a coding practice that could possibly have other unrelated
effects?

-- 
Rich