On Tue, Oct 20, 2015 at 5:22 AM, Alexis Ballier <[email protected]> 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
