| 1 |
On 08/18/2013 12:39 PM, Ulrich Mueller wrote: |
| 2 |
> |
| 3 |
> The current epatch() would remain available in eutils.eclass for cases |
| 4 |
> where its more advanced modes of operation are needed. |
| 5 |
> ... |
| 6 |
> 2. Should the function do automatic -p* detection, or should it |
| 7 |
> default to -p1? Both would be overridable by an explicit -p* |
| 8 |
> option. There are good arguments for either variant (see the |
| 9 |
> above-mentioned bug). |
| 10 |
|
| 11 |
With epatch() still available, my instinct is to leave the -p detection |
| 12 |
out of PMS for now. The implementation details will be messy otherwise, |
| 13 |
and doing so encourages people to hack their patches to -p1 if they want |
| 14 |
to drop the eutils dependency, so there's some slight encouragement to |
| 15 |
clean things up. |
| 16 |
|
| 17 |
As you mentioned in the bug, -p detection is more desirable for the user |
| 18 |
patches feature, since users might not know how to mangle the hunk |
| 19 |
headers. Furthermore, they aren't the ones calling the ebuild function, |
| 20 |
so they can't override the default -p level. |
| 21 |
|
| 22 |
On the other hand, we trust devs to verify that the -p detection in |
| 23 |
epatch() actually works correctly for a given ebuild. Will a user do the |
| 24 |
same, or will he assume that if it compiles it worked? It may be a tiny |
| 25 |
bit safer to ask the user to supply a patch at a known depth. |
Archives