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

[Rich Freeman <rich0@gentoo.org>]

On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> But there is something important we've overlooked: should eclasses that
> export src_prepare call eapply_user ? I think yes, otherwise they'd
> make packages inheriting them violate the 'at least once rule'.

This sort of thing has been discussed by the council, though we didn't
make a specific recommendation on the eclass authoring side.  The
exactly once language was specifically chosen to force eclass/ebuild
authors to consider this problem, because bad things happen if you
don't.

I'd argue that eclasses should fall into two categories:
1.  Utility eclasses.  These are things like git.eclass that export
useful functions that ebuilds can call.  They shouldn't export phase
functions, so ebuild authors can use as many of these as they want and
they'll never conflict.
2.  Do-everything eclasses.  These are things like the kde eclasses
which operate with the design that the packages themselves do almost
nothing, and all the work is in the eclass.  It allows things like
splitting up kde ebuilds without having a ton of duplicated code in
hundreds of packages.  These should export phase functions, and you
tend to run into all kinds of problems if you try to use more than one
of them, so you shouldn't.

So, if you're writing a utility eclass you shouldn't be exporting
src_prepare, and so you're fine.  By all means export a function
designed to be called during src_prepare, but don't export the phase
itself.

If you're writing a do-everything eclass then do whatever makes the
most sense.  Most likely you're co-maintianing every package that uses
the eclass anyway.  Just document how you're doing it.

The real problem is when people try to do something in-between, which
happens with a lot of language-based eclasses it seems.  Then when you
have some package that uses three different languages in its build
system you get to deal with a mess of which eclass should be doing
what.  We really need to get away from this.

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.

However, IMO we should be trying to move away from these kinds of
eclasses (other than the two cases above).  It is really pretty to
just type inherit foo at the top of your ebuild and watch the magic
happen, until it isn't.

As has already been pointed out, if we allow eapply_user to be called
anything other than exactly once, then you run into various situations
where it ends up not being called correctly.  And we can hardly make
it a NOOP every time but the last time unless we do two-pass
src_prepare or solve the halting problem, neither of which is
appealing.

-- 
Rich