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

[Alexis Ballier <aballier@gentoo.org>]

On Sat, 17 Oct 2015 23:24:47 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 17 Oct 2015 22:08:38 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Fri, 16 Oct 2015 20:42:20 +0200
> > Ulrich Mueller <ulm@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.

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

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

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.

Alexis.