| 1 |
On Sat, 17 Oct 2015 22:08:38 +0200 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
|
| 4 |
> On Fri, 16 Oct 2015 20:42:20 +0200 |
| 5 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 6 |
> |
| 7 |
> > [Resending since my first message didn't make it to -dev-announce.] |
| 8 |
> > |
| 9 |
> > The first draft of EAPI 6 is ready. I shall post it as a series of |
| 10 |
> > 22 patches following this message in the gentoo-pms mailing list. |
| 11 |
> > |
| 12 |
> > Please review. The goal is to have the draft ready for approval in the |
| 13 |
> > council's November meeting. |
| 14 |
> |
| 15 |
> Sorry for coming very late on this, but what is the rationale behind |
| 16 |
> setting in stone an 'eapply' different to an 'epatch' that has been |
| 17 |
> widely tested for decades now ? Or even defining eapply in PMS ? |
| 18 |
|
| 19 |
How many decades, exactly? ;-) |
| 20 |
|
| 21 |
> I can understand "eapply is a function that applies patches" isn't nice |
| 22 |
> for a spec., but we've already seen in the past gnu patch changing |
| 23 |
> behavior wrt what is an acceptable patch between versions, bsd 'patch' |
| 24 |
> command behaves slightly differently than gnu patch (read: is unusable |
| 25 |
> with epatch), etc. |
| 26 |
> One can argue that gnu patch changing behavior is part of life, but |
| 27 |
> what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch, |
| 28 |
> 'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch |
| 29 |
> for ebuilds, but I don't think profile.bashrc should mess up with what |
| 30 |
> is mandated by PMS. |
| 31 |
|
| 32 |
I think the goal is to actually require GNU patch, likely even |
| 33 |
a specific version of it. |
| 34 |
|
| 35 |
> Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts |
| 36 |
> -p0 patches by default here. Or when $S is actually a subdir of a |
| 37 |
> repository, this will make standard git format-patch generated patches |
| 38 |
> unusable. |
| 39 |
|
| 40 |
The poor man's autodetection implemented in epatch was... well, poor. |
| 41 |
It had its corner cases when it failed hard, it was complex and made |
| 42 |
error handling PITA (which patch invocation really failed?!). |
| 43 |
|
| 44 |
It's trivial to change patch to -p1 (I think patchutils can do that). |
| 45 |
It's beneficial to keep patches with predictable directory structure. |
| 46 |
And after all, you can use 'eapply -pN' explicitly. And yes, I know you |
| 47 |
hate having to think instead of having some random hidden implicit, |
| 48 |
likely-to-fail logic do it for you. |
| 49 |
|
| 50 |
-- |
| 51 |
Best regards, |
| 52 |
Michał Górny |
| 53 |
<http://dev.gentoo.org/~mgorny/> |
Archives