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

[Rich Freeman]

On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <aballier@g.o> wrote:
>
> However, as you say, putting it in cmake-utils needs to be properly
> thought so that it doesn't conflict with other eclasses: Hence the need
> to properly define what eclasses should call eapply_user and apply
> patches and what should not.
>

That is my main concern.  Maybe a package uses cmake and ant.  Patches
could affect either.  With an automagic design you might have to run
half of each src_configure, then apply patches, then run the other
half of each src_configure.

> Your initial argument was very convincing, but under those conditions,
> it seems way much saner to make eapply_user idempotent and be done.
> (and maybe in addition require informally that eapply_user is called
> after applying patches, but that'd fall under good practices rather
> than rules)

The only danger here is that later phase functions to run would be
operating on already-patched sources, when they expect to be running
on unpatched sources.  I imagine that usually wouldn't be a problem,
but it of course could be one.

I do get your analogy to eapply_user not being in the default phase function.

This all falls into that general category of correctness vs
convenience.  It is more convenient if you can just call eapply_user
at a suboptimal point and not have to mess with your ebuilds.  The
same argument could be made for running all the inherited eclass phase
functions and not just one of them.  The issue is that this can break
in lots of hard-to-predict ways.  I'd rather see things refactored to
deal with this in a more sane manner.

That actually makes me wonder if the better solution is to add another
phase - such as src_postprepare or something like that, where you'd
run autotools or whatever.  If that were done then you could also make
hasufell happy by just having the PM do the patching after
src_prepare.  Maybe that can go in EAPI7.  :)

-- 
Rich