On 11/06/2014 02:16 PM, Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 13:42:43 -0800
> Zac Medico <zmed...@gentoo.org> wrote:
>
>> On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
>>> 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.
>
> If the order is important, then the ebuild should call each phase or
> utility function explicitly. Expecting the order of inheritance to
> convey the same thing instead of making explicit calls might work from
> the package manager's perspective, but the ebuild writer is lost in the
> woods. With that in mind we might argue that a change in the order of
> inheritance should never cause a different outcome.
>
>> In the context of future.eclass, eutils and multilib could simply
>> check if the relevant functions were defined earlier, and die in that
>> case.
>
> Would the bash internal `readonly -f' work for that?
Maybe, but the error message would be cryptic. I was thinking something
like this:
declare -F get_libdir >/dev/null && \
die "multilib.eclass must be inherited before future.eclass"
>>> 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.
>
> Well, that's convenient but you should probably not start relying on
> it now.
I think it would be a fine assumption, and Ciaran has noted that PMS
already specifies that inherit parameters are considered in order.
> In that case we might want to discuss inheriting in
> alphabetical order and numbering the eclasses cleverly, too. Or rename
> this one to zfuture.eclass.
I understand your intentions, but I don't think that's the right
solution. I agree with Ciaran's assertion that "it would be much easier
if people just stopped writing "clever" eclasses and didn't mix utility
functions and phase functions within a single eclass".
--
Thanks,
Zac
