On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 12:40:33 -0800
> Zac Medico <zmed...@gentoo.org> wrote:
>
>> On 11/06/2014 12:11 PM, Michał Górny wrote:
>>> # multilib.eclass collisions
>>> get_libdir() { future_get_libdir "${@}"; }
>>> # eutils.eclass collisions
>>> einstalldocs() { future_einstalldocs "${@}"; }
>>
>> This collision handling mechanism seems pretty reasonable.
>> Alternatively, maybe it could die if the functions are already
>> defined, and advise the developer that future should be inherited
>> later than multilib and eutils.
>
> I'm not aware of any current definition of order in eclass inheritance.
Maybe PMS doesn't say anything about the order (yet). However, I'm
fairly sure that all package managers process eclasses in the same order
that they are passed as arguments to inherit. Otherwise, eclasses would
not be able to properly override functions defined by eclasses earlier
in the inherit chain.
In the context of future.eclass, eutils and multilib could simply check
if the relevant functions were defined earlier, and die in that case.
> We sure have issues with inheriting eclasses in a different order giving
> different results now. Is this something that's in the works for a
> future EAPI, then?
No, but as said, I'm fairly sure that all package managers process
eclasses in the same order that they are passed as arguments to inherit.
--
Thanks,
Zac
