1 |
On Fri, 16 Oct 2015 20:42:20 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> [Resending since my first message didn't make it to -dev-announce.] |
5 |
> |
6 |
> The first draft of EAPI 6 is ready. I shall post it as a series of |
7 |
> 22 patches following this message in the gentoo-pms mailing list. |
8 |
> |
9 |
> Please review. The goal is to have the draft ready for approval in the |
10 |
> council's November meeting. |
11 |
|
12 |
Sorry for coming very late on this, but what is the rationale behind |
13 |
setting in stone an 'eapply' different to an 'epatch' that has been |
14 |
widely tested for decades now ? Or even defining eapply in PMS ? |
15 |
|
16 |
I can understand "eapply is a function that applies patches" isn't nice |
17 |
for a spec., but we've already seen in the past gnu patch changing |
18 |
behavior wrt what is an acceptable patch between versions, bsd 'patch' |
19 |
command behaves slightly differently than gnu patch (read: is unusable |
20 |
with epatch), etc. |
21 |
One can argue that gnu patch changing behavior is part of life, but |
22 |
what worries me more is the BSDs: e.g. on gfbsd, 'patch' is bsd patch, |
23 |
'gpatch' is gnu patch; we use profile.bashrc to alias patch to gpatch |
24 |
for ebuilds, but I don't think profile.bashrc should mess up with what |
25 |
is mandated by PMS. |
26 |
|
27 |
|
28 |
Also, mandating -p1 seems quite limiting: e.g. 'svn diff -rX:Y' extracts |
29 |
-p0 patches by default here. Or when $S is actually a subdir of a |
30 |
repository, this will make standard git format-patch generated patches |
31 |
unusable. |
32 |
|
33 |
|
34 |
Alexis. |