Proposal: require sorting inherit arguments (eclasses) lexicographically except for where we need to consider phase export order. The exception is intended for where phase export order is important, e.g. multilib-minimal.eclass which exposes almost all common phase functions. Rationale: * Principle of least surprise. It's non-trivial to parse the effective exported phases if the inherit line is not lexicographically sorted. * Encourages authors to think carefully about inherit order at time of writing. * Arbitrary order may mean the ebuild works "accidentally". The order should be minimally deviant from lexicographical sorting in order to best understand the flow of execution and effective phase order. * Future-proofing. By clearly defining this as our expectation, eclasses which need to be placed last must *clearly* state this. This should be done anyway though. * This is already a de facto rule enforced during proxy-maint reviews and, for me at least, during recruitment and mentoring. We do exactly the same thing with KEYWORDS, which as far as I know, isn't actually explicitly stated.
Not sure if making that a policy is a good idea. If we require a specific ordering, then people will inevitably rely on that ordering, even if they shouldn't. I'd even go so far and say that an ebuild should work regardless of inherit order, i.e., resolve any phase export conflicts by explicitly defining that function. I'm also pretty sure that this has been discussed before (but fail to find it).
I've already tried https://bugs.gentoo.org/show_bug.cgi?id=710922
Better as a style suggestion I guess.
