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