On Sat, 17 Oct 2015 22:47:28 +0200 Ulrich Mueller <u...@gentoo.org> 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.
