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?
> > 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. 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.
jer
