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

[Rich Freeman <rich0@gentoo.org>]

(To avoid repeating the same exception over and over, please
understand that nothing said below is intended to apply to the
do-everything eclasses used by KDE/etc, where the eclass and ebuilds
are carefully maintained in conjunction with each other.)

On Mon, Oct 19, 2015 at 9:34 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> However, by somewhat throwing away the problem, you're just asking for
> a complete mess

The intent of the next paragraph was to not throw away the problem.

>
>> I'd say the best approach for compatibility if you have an existing
>> eclass and it already exports src_prepare is to not call eapply_user
>> unless it firmly falls into the #2 category above.
>
> Replace 'not call eapply_user' by 'not export src_prepare' and I'd
> agree with you if going a bit further by ensuring there is no hidden
> problem:

Well, taken together my recommendation does amount to:
1.  Avoid exporting src_prepare at all.
2.  If you do export src_prepare, then don't call eapply_user.

That means that anybody creating an ebuild that uses an eclass which
does export src_prepare should define the phase in the ebuild, call
the various eclass src_prepares in the appropriate orders, and call
eapply_user in the appropriate place.  Since the ebuild needs to be
modified to use EAPI6 it can be done at that time.

> Going through each eclass exporting src_prepare and defining
> which should export it and which should not. I hope what you say is
> sufficient, but it'd be a bad idea to set this in stone for realizing
> in a few months that this forces people to write crappy code for having
> some eclasses to co-exist nicely.

You already need to write crappy code to get some eclasses to co-exist
nicely, because they export conflicting phase functions assuming
they're the only eclass you'll use.

The eclass docs already indicate which ones export src_prepare.  If
you're using one of those you need to make sure you're overriding it,
and calling eapply_user.  As long as eclasses don't call eapply_user
we're fine.

>
> Some temptative list of which could be annoying (as in, do not seem to
> be 'do everything' eclasses):
>
> bzr.eclass
>   -> patches (now useless) and bootstrap script, dropping it might
>   encounter some resistance
> cuda.eclass
>   -> appends cflags, could easily be moved to src_configure and not
>   exported
> java-pkg-opt-2.eclass
>   -> sanity checks & autofixing, not sure how to handle
> subversion.eclass
>   -> patches (now useless) and bootstrap script, dropping it might
>   encounter some resistance
> vala.eclass
>   -> sets up some kind of virtual env, could very well be src_configure

The solution to these kinds of problems isn't to remove functionality
from the eclass, but rather just export a function that ebuilds can
call from src_prepare at the appropriate time, rather than just trying
to do it all magically.

This was discussed fairly extensively at:
http://article.gmane.org/gmane.linux.gentoo.devel/92581

I'm not attempting to tackle that now, but as a step in the right
direction I suggest that eclasses not try to call eapply_user in
general, and then we don't have to worry about the situation where you
want to use three eclasses which all try to call it.

I think the long-term solution is to stop exporting phase functions in
eclasses.  I'd recommend stripping the ability to do so at all from
PMS, except for the whole KDE exception which makes sense to me.

-- 
Rich