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

[Ulrich Mueller]

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

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

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

Ulrich