| 1 |
On 27 August 2013 22:14, Michał Górny <mgorny@g.o> wrote: |
| 2 |
|
| 3 |
> Dnia 2013-08-18, o godz. 18:39:56 |
| 4 |
> Ulrich Mueller <ulm@g.o> napisał(a): |
| 5 |
> |
| 6 |
> > 3. So far, we don't have a good name for the function. |
| 7 |
> |
| 8 |
> eapply. |
| 9 |
> |
| 10 |
> - consistent with 'git apply', |
| 11 |
> - short, |
| 12 |
> - e* prefix, |
| 13 |
> - no known collisions. |
| 14 |
> |
| 15 |
> I wouldn't call it perfect since the name may be a little unclear. |
| 16 |
> However, considering that all the names using word 'patch' would be |
| 17 |
> confusing (especially to new users who will confuse how two '*patch' |
| 18 |
> functions differ) it seems like a good idea. |
| 19 |
> |
| 20 |
> -- |
| 21 |
> Best regards, |
| 22 |
> Michał Górny |
| 23 |
> |
| 24 |
|
| 25 |
I'd suggest epatch_native , its clear in its intent, and its clear in the |
| 26 |
difference from the eutils format. |
| 27 |
|
| 28 |
I had a side thought were I imagined it might be plausible to have it just |
| 29 |
called "epatch" ( with epatch_native being a resolution alias to avoid the |
| 30 |
eutils version ), because inheriting eutils would shadow the native one |
| 31 |
with the eutils form, but then realised that path is not viable to us by |
| 32 |
proxy of eutils doing more than just patching, making the effort to use |
| 33 |
native patches more effort instead of less. |
| 34 |
|
| 35 |
I'd imagine transitioning from epatch to epatch_native would be quite easy |
| 36 |
to do on a large amount of ebuilds as long as authors have already had |
| 37 |
consistent patch generation approaches, but the shadow based mechanism on |
| 38 |
serious thought gives no real benefit with room for user error. |
| 39 |
|
| 40 |
-- |
| 41 |
Kent |
Archives