On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
<ciaran.mccre...@googlemail.com> wrote:
> On Thu, 6 Nov 2014 22:32:17 +0100
> Jeroen Roovers <j...@gentoo.org> 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. 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?
>
> An EAPI solution to this is hard to work out. 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.
>For anybody interested in this the topic came up in the council EAPI discussions especially on June 17th, and in bug: https://bugs.gentoo.org/show_bug.cgi?id=422533 I think we are well-served by taking Ciaran's advice here. Utility eclasses should just passively export functions. Anything that does overrides should really be designed for special situations and not widespread use where it would potentially conflict with other eclasses that do the same. So, a KDE all-in-one eclass might not be bad. A perl all-in-one eclass would be more troublesome, especially if KDE had any packages written in perl. Just to pick somewhat random and perhaps not great examples. -- Rich
