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

[Alexis Ballier]

On Sat, 17 Oct 2015 22:47:28 +0200
Ulrich Mueller <ulm@g.o> wrote:

> >>>>> On Sat, 17 Oct 2015, Alexis Ballier wrote:
>
> > Sorry for coming very late on this, but what is the rationale behind
> > setting in stone an 'eapply' different to an 'epatch' that has been
> > widely tested for decades now ? Or even defining eapply in PMS ?
>
> The rationale is that we cannot apply patches in the default
> src_prepare() unless there is a patch function in the package manager
> itself. Obviously the default phase cannot call a function from an
> eclass.

well, that was the idea behind base.eclass :)
why not just improving it ?

or give proper scoping to inherit wrt EXPORT_FUNCTIONS, ala python:
'from base inherit src_prepare'

> > I can understand "eapply is a function that applies patches" isn't
> > nice for a spec., but we've already seen in the past gnu patch
> > changing behavior wrt what is an acceptable patch between versions,
> > bsd 'patch' command behaves slightly differently than gnu patch
> > (read: is unusable with epatch), etc.
> > One can argue that gnu patch changing behavior is part of life, but
> > what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd
> > patch, 'gpatch' is gnu patch; we use profile.bashrc to alias patch
> > to gpatch for ebuilds, but I don't think profile.bashrc should mess
> > up with what is mandated by PMS.
>
> The spec for eapply mentions that it will accept GNU patch options,
> but maybe we should be more explicit and say that eapply must call
> GNU patch.

ok; or just make it explicit that eapply must run with ebuild env (since
gnu patch is already required in ebuild env)

> > Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y'
> > extracts -p0 patches by default here. Or when $S is actually a
> > subdir of a repository, this will make standard git format-patch
> > generated patches unusable.
>
> Limiting the level to -p1 (and not doing autodetection) was a design
> decision. eapply is really meant for simple cases like default
> src_prepare applying patches listed in the PATCHES variable.
> For anything that is more complicated there will still be epatch.


yes, I understand that, but this one was more intended for the
rationale and for eapply_user:
- why should I ever call eapply instead of epatch ?
- why should I ever want eapi6 src_prepare instead of
  base_src_prepare ?
- what do I, as en ebuild writer, gain from this?
- what does the PM gain from this ?

As for eapply_user: Since it seems perfectly fine to have eapply_user a
noop, and most parts are implementation defined, why mandating
eapply_user to use such a limited eapply instead of leaving it
implementation defined ?


Alexis.