| 1 |
>>>>> On Sun, 18 Aug 2013, Ulrich Mueller wrote: |
| 2 |
|
| 3 |
> For EAPI 6, introduction of a patch applying function to the package |
| 4 |
> manager itself is being discussed. This would serve two purposes: |
| 5 |
> - support for PATCHES variable in a default src_install phase |
| 6 |
> - a function to apply user patches |
| 7 |
|
| 8 |
> In bug 463768 the conclusion so far was that implementing the full |
| 9 |
> epatch function in the package manager is not feasible. Therefore, |
| 10 |
> the package manager's implemention would have reduced functionality. |
| 11 |
> The current epatch() would remain available in eutils.eclass for |
| 12 |
> cases where its more advanced modes of operation are needed. |
| 13 |
|
| 14 |
> The feature list we came up with (see bug 463768 comment 32) |
| 15 |
> includes support for regular patch files, of course. It also |
| 16 |
> includes support for directories, with patches applied in lexical |
| 17 |
> order of their filenames (only files named *.diff and *.patch). |
| 18 |
|
| 19 |
> So, the questions that I'd like to ask are: |
| 20 |
|
| 21 |
Summarising the answers below. |
| 22 |
|
| 23 |
> 1. Is the above set of features reasonable? |
| 24 |
|
| 25 |
Nobody has replied to this one, so I assume that there are no |
| 26 |
objections. |
| 27 |
|
| 28 |
> 2. Should the function do automatic -p* detection, or should it |
| 29 |
> default to -p1? Both would be overridable by an explicit -p* |
| 30 |
> option. There are good arguments for either variant |
| 31 |
> (see the above-mentioned bug). |
| 32 |
|
| 33 |
Rick "Zero_Chaos" Farina: |
| 34 |
| Pretty please autodetection. It's a very nice feature that we seem |
| 35 |
| to already have sanely implemented. |
| 36 |
|
| 37 |
Michael Orlitzky: |
| 38 |
| With epatch() still available, my instinct is to leave the -p |
| 39 |
| detection out of PMS for now. The implementation details will be |
| 40 |
| messy otherwise, [...] |
| 41 |
|
| 42 |
Michał Górny: |
| 43 |
| I'm all for -p1. Instead of auto-detecting stuff on user's side, |
| 44 |
| we should provide developers with a simple tool that would |
| 45 |
| automatically 'fix' patches. |
| 46 |
|
| 47 |
Not many new arguments, beyond what we had in the bug already. I'd |
| 48 |
suggest that we follow the KISS principle and go with -p1. There's |
| 49 |
always epatch if you need more fancy stuff. |
| 50 |
|
| 51 |
> 3. So far, we don't have a good name for the function. |
| 52 |
|
| 53 |
Only suggestion so far is "dopatch". I don't really like it because |
| 54 |
other do* functions are called from src_install. But if nobody comes |
| 55 |
up with a better name, then it will be dopatch. |
| 56 |
|
| 57 |
Ulrich |
Archives