On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman <ri...@gentoo.org> wrote: [...] > > > > 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.
Probably, indeed. > 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. Heh, going OT, I guess I'd be on the other side: kill the autotools-centric default phases and move everything to eclasses' exported functions :) (or make default phases much more friendly to non-autotools build systems, but that'd likely double pms size with useless considerations) > 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? Yep; I can't see any real harm, but this is probably based on a limited view of the big picture. However, I do think the practice should be discouraged, but 'let be' in specific cases like for eclasses co-existence. Actually, just like any other (non breaking) QA issue is handled I think.
