| 1 |
On Fri, 27 Apr 2012 14:15:35 +0000 (UTC) |
| 2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
| 3 |
|
| 4 |
> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: |
| 5 |
> |
| 6 |
> > On 04/26/2012 03:08 PM, Duncan wrote: |
| 7 |
> >> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: |
| 8 |
> >>> Also, don't forget to consider the possibility of interference |
| 9 |
> >>> between FEATURES=userpatch and epatch_user (applying same patches |
| 10 |
> >>> twice). |
| 11 |
> >> |
| 12 |
> >> The existing phaselock-file solution should continue to work |
| 13 |
> >> there. |
| 14 |
> |
| 15 |
> > Having the package manager interact with an eclass function like |
| 16 |
> > epatch_user is ugly, and it's unnecessary since we can pull all of |
| 17 |
> > the pieces into the package manager in EAPI 5. Any eclasses that |
| 18 |
> > currently call epatch_user can have a conditional like this: |
| 19 |
> > |
| 20 |
> > if has $EAPI 0 1 2 3 4 ; then |
| 21 |
> > epatch_user |
| 22 |
> > else |
| 23 |
> > apply_user_patches_here |
| 24 |
> > fi |
| 25 |
> |
| 26 |
> But that doesn't solve the problem of making it globally available, |
| 27 |
> since it only applies to packages/eclasses that already call |
| 28 |
> epatch_user for EAPIs thru current EAPI-4. |
| 29 |
> |
| 30 |
> In ordered to make it globally available, it cannot simply be an |
| 31 |
> EAPI-5 thing, it must apply to all current ebuilds whether they (or |
| 32 |
> an inherited eclass) call epatch_user or not. Which means that |
| 33 |
> conflict with the existing epatch_user is unavoidable, since it will |
| 34 |
> either try to run twice where it's already called, or it won't run at |
| 35 |
> all where it's not. |
| 36 |
> |
| 37 |
> Tho I guess one solution to that would be to change the name of the |
| 38 |
> patches dir for the new version, calling it /etc/portage/patches2/ or |
| 39 |
> some such. Another solution could be to make the existing |
| 40 |
> epatch_user call a no-op, and force post-src-prepare invocation on |
| 41 |
> EAPIs 1-4. |
| 42 |
> |
| 43 |
> But both of these have problems in that they nullify the work done in |
| 44 |
> existing ebuilds to locate the call correctly, before eautoreconf or |
| 45 |
> whatever. |
| 46 |
|
| 47 |
We could finally decide it'll be a Portage internal feature, and modify |
| 48 |
epatch_user() to export some Portage-specific indication that user |
| 49 |
patches were applied. |
| 50 |
|
| 51 |
-- |
| 52 |
Best regards, |
| 53 |
Michał Górny |
Archives