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

[Alexis Ballier]

On Mon, 19 Oct 2015 15:49:06 -0400
Rich Freeman <rich0@g.o> wrote:

> 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.

This is my concern too and where I am fearing crappy code :)


> > 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.

It's not about correctness vs convenience: eapply_user idempotent
doesn't prevent from doing it correctly. It makes it possible to do it
incorrectly though, just like any turing-complete language actually, but
it is not clear at all what would be the ratio of "incorrect convenient
usage" vs "correct convenient usage": if 99.9% of the tree is fine,
then convenience is clearly worth it instead of changing everything to
accommodate the remaining 0.1%.
eapply_user dying on second call, defined in PMS, OTOH, prevents
such flexibility and thus raises a lot of design questions that, as seen
here, don't seem to have a clear answer yet and for which it could
indeed be worth refactoring.


I can't find an example of where the guideline "apply ebuild
patches before eapply_user" would not be sufficient: After all,
all subsequent phases will also run on user-patched sources and there
are millions of ways to make a patch break a package.

> 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.  :)

src_patch ? :)