Re: [gentoo-dev] RFC: future.eclass

[Rich Freeman]

On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
<ciaran.mccreesh@××××××××××.com> wrote:
> On Thu, 6 Nov 2014 22:32:17 +0100
> Jeroen Roovers <jer@g.o> wrote:
>> On Thu, 06 Nov 2014 12:40:33 -0800
>> Zac Medico <zmedico@g.o> 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