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

[Rich Freeman <rich0@gentoo.org>]

On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Mon, 19 Oct 2015 15:49:06 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
> 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%.

Sure, but that is the point of correctness vs convenience.  The goal
of correctness is to make it not possible to do things incorrectly,
even if that makes it harder to do things correctly.  The goal of
convenience is to make it easier to do things correctly, even if it
makes it possible to do things incorrectly.  It is a tradeoff.

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

It has a perfectly clear answer - just don't run eapply_user in eclasses.

It isn't a convenient answer, perhaps, but it will always work.

Apologies to the rest of the Council if this wasn't on everybody's
radar back when we were discussing EAPI6.  I thought we were mostly on
the same page about taking this sort of approach already.  I guess it
doesn't hurt to be more explicit and less clever in the wording.  I
don't think we wanted to outright ban eclass use of eapply_user though
- it is still appropriate to use in situations where ebuilds are just
wrappers around an eclass.

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

How would you apply ebuild patches before eapply_user when you have
multiple eclasses all applying patches and all calling eapply_user?

Adding another phase may be the cleaner solution.  It is a bit late to
be talking about that, however, for EAPI6.

-- 
Rich