1 |
On Thu, 06 Nov 2014 12:40:33 -0800 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> On 11/06/2014 12:11 PM, Michał Górny wrote: |
5 |
> > # multilib.eclass collisions |
6 |
> > get_libdir() { future_get_libdir "${@}"; } |
7 |
> > # eutils.eclass collisions |
8 |
> > einstalldocs() { future_einstalldocs "${@}"; } |
9 |
> |
10 |
> This collision handling mechanism seems pretty reasonable. |
11 |
> Alternatively, maybe it could die if the functions are already |
12 |
> defined, and advise the developer that future should be inherited |
13 |
> later than multilib and eutils. |
14 |
|
15 |
I'm not aware of any current definition of order in eclass inheritance. |
16 |
We sure have issues with inheriting eclasses in a different order giving |
17 |
different results now. Is this something that's in the works for a |
18 |
future EAPI, then? |
19 |
|
20 |
|
21 |
jer |