On Sun, 18 Oct 2015 10:47:01 +0200 Alexis Ballier <aball...@gentoo.org> wrote:
> On Sat, 17 Oct 2015 23:24:47 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > On Sat, 17 Oct 2015 22:08:38 +0200 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > On Fri, 16 Oct 2015 20:42:20 +0200 > > > Ulrich Mueller <u...@gentoo.org> wrote: > > > > > > > [Resending since my first message didn't make it to > > > > -dev-announce.] > > > > > > > > The first draft of EAPI 6 is ready. I shall post it as a series of > > > > 22 patches following this message in the gentoo-pms mailing list. > > > > > > > > Please review. The goal is to have the draft ready for approval > > > > in the council's November meeting. > > > > > > 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 ? > > > > How many decades, exactly? ;-) > > from 1.5 to 1.6 I'd say :p > > [...] > > > 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. > > > > The poor man's autodetection implemented in epatch was... well, poor. > > It had its corner cases when it failed hard, it was complex and made > > error handling PITA (which patch invocation really failed?!). > > There's a log for understanding which invocation failed. Yes, and it is a very friendly log which contains a few invocations, each having some random failures and successes. Guessing is usually faster. > > It's trivial to change patch to -p1 (I think patchutils can do that). > > It is. But the above cases were not whether it is possible, but rather > desirable. Consistency is desirable. There is world outside ebuilds, and they need to apply patches sometimes. > > It's beneficial to keep patches with predictable directory structure. > > And after all, you can use 'eapply -pN' explicitly. And yes, I know > > you hate having to think instead of having some random hidden > > implicit, likely-to-fail logic do it for you. > > Well, there's that, but I also wonder why every single ebuild uses > epatch and not 'patch -p1 < ...' directly if epatch is so bad... Because 'patch -p1 < ... || die' needs to be repeated multiple times for each file. Simple as that. > But my point was not there: I still fail to understand why we should > set in stone something not so well tested in comparison to epatch, that > doesn't seem to provide any gain besides a default phase that an eclass > can also provide, that has less features and that can't be > changed/fixed easily. epatch is not well tested. Some of its branches are. Some of its code was changed due to failures. We're reusing the parts of epatch that make sense. Otherwise, epatch would take more space in PMS than all stuff about ebuilds added together, would require change in EAPI every 6 months, plus a number of bugfix releases due to broken implementations of over-complex concept. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgp31Q6G2g8mH.pgp
Description: OpenPGP digital signature
