1 |
On 11 May 2015 22:44, Benda Xu wrote: |
2 |
> In libtool.eclass[1], it is mentioned in the comments of elt_patch_dir() |
3 |
> that |
4 |
> |
5 |
> # If an overlay has eclass overrides, but doesn't actually override the |
6 |
> # libtool.eclass, we'll have ECLASSDIR pointing to the active overlay's |
7 |
> # eclass/ dir, but libtool.eclass is still in the main Gentoo tree. So |
8 |
> # add a check to locate the ELT-patches/ regardless of what's going on. |
9 |
> |
10 |
> |
11 |
> But quoting from PMS[2], "ECLASSDIR: The full path to the master |
12 |
> repository’s eclass directory", ECLASSDIR always points to |
13 |
> ${PORTDIR}/eclass, regardless how the repos.conf is configured. |
14 |
> |
15 |
> |
16 |
> Thus as long as ELT-patches dir of the gx86 tree exists, there is no way |
17 |
> to tell libtool.eclass to use it in my overlay. |
18 |
|
19 |
that's the point of the change -- to locate ELT-patches that matches the |
20 |
libtool.eclass regardless of what the overlay is doing. the intention was not |
21 |
to support local sets of ELT-patches while still using the libtool.eclass from |
22 |
elsewhere. see the bug referenced in the commit: |
23 |
https://bugs.gentoo.org/389009 |
24 |
|
25 |
if you duplicate libtool.eclass in your overlay, it should find ELT-patches |
26 |
there. considering libtool.eclass is pretty tightly coupled to the contents of |
27 |
that dir, i'm not sure supporting overlays is desirable. |
28 |
-mike |