| 1 |
On 27/04/12 17:15, Duncan wrote: |
| 2 |
> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: |
| 3 |
>> Having the package manager interact with an eclass function like |
| 4 |
>> epatch_user is ugly, and it's unnecessary since we can pull all of the |
| 5 |
>> pieces into the package manager in EAPI 5. Any eclasses that currently |
| 6 |
>> call epatch_user can have a conditional like this: |
| 7 |
>> |
| 8 |
>> if has $EAPI 0 1 2 3 4 ; then |
| 9 |
>> epatch_user |
| 10 |
>> else |
| 11 |
>> apply_user_patches_here |
| 12 |
>> fi |
| 13 |
> |
| 14 |
> But that doesn't solve the problem of making it globally available, since |
| 15 |
> it only applies to packages/eclasses that already call epatch_user for |
| 16 |
> EAPIs thru current EAPI-4. |
| 17 |
> |
| 18 |
> In ordered to make it globally available, it cannot simply be an EAPI-5 |
| 19 |
> thing, it must apply to all current ebuilds whether they (or an inherited |
| 20 |
> eclass) call epatch_user or not. Which means that conflict with the |
| 21 |
> existing epatch_user is unavoidable, since it will either try to run |
| 22 |
> twice where it's already called, or it won't run at all where it's not. |
| 23 |
|
| 24 |
According to the source, calling it twice is perfectly safe. |
Archives