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

[Alexis Ballier <aballier@gentoo.org>]

On Tue, 20 Oct 2015 06:00:15 -0400
Rich Freeman <rich0@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.