On Sun, 18 Oct 2015 10:48:47 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> On Sun, 18 Oct 2015 10:31:09 +0200 > Alexis Ballier <aball...@gentoo.org> wrote: > > > 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 ? > > Let me Ciaran the answer for you: because we want a stable API. We > don't want random eclass that random developer will randomly change > every second month, accidentally breaking a number of ebuilds. The concept of stable API when you rely on external tools, esp. tools like patch full of heuristics, is flawed already. [...] > > 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 ? > > Because it's built-in, simpler, faster and more failure-proof. "built-in, simpler, faster": this has never been an argument but why not :) (we wouldnt use bash if it were...) "more failure-proof" has yet to be asserted in the field > > - why should I ever want eapi6 src_prepare instead of > > base_src_prepare ? > > base.eclass is deprecated. You are going to get in trouble for using > it. From this I understand that it suffices that I step up as its maintainer :p > > - what do I, as en ebuild writer, gain from this? > > Reliable patching. Unlike epatch, eapply will not succeed when > the patch unexpectedly applied to the wrong directory. Why not, but when exactly would eapply fail where epatch wouldn't while it should have ? > > 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 ? > > Principle of least surprise. Reusability of patches. A noop is fine, but if PM does implement it, PM must abort if a -p2 patch appears in an implementation defined directory: Something sounds wrong here.
