1 |
On Tue, 14 Aug 2012 21:56:38 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Tue, 14 Aug 2012 22:54:13 +0200 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> > On Tue, 14 Aug 2012 21:45:56 +0100 |
7 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
8 |
> > > On Tue, 14 Aug 2012 11:44:49 +0200 |
9 |
> > > Michał Górny <mgorny@g.o> wrote: |
10 |
> > > > As some of you may have noticed, lately introduced 'double |
11 |
> > > > include preventions' have caused changes in effective phase |
12 |
> > > > functions in a few ebuilds. Also, often it is undesirable that |
13 |
> > > > change in inherits of an eclass may cause an undesired change |
14 |
> > > > of exported functions. |
15 |
> > > |
16 |
> > > The problem here is that eclasses aren't clearly split between |
17 |
> > > "utility" and "does stuff", so people are inheriting "does stuff" |
18 |
> > > eclasses to get utilities. The fix is to stop having stupidly huge |
19 |
> > > complicated eclasses; changing inherit behaviour is just |
20 |
> > > wallpapering over the gaping hole. |
21 |
> > |
22 |
> > Soo, how do you propose to handle bug 422533 without changing |
23 |
> > inherit behavior? |
24 |
> |
25 |
> We can't change inherit behaviour in EAPI 5 anyway since it's a global |
26 |
> scope function, so I was planning to ignore it and hope that by the |
27 |
> time EAPI 6 comes along, people will have learned not to write huge |
28 |
> eclasses that do more than one thing. |
29 |
|
30 |
And why? I believe we have quite a clean rule that *EAPI goes before |
31 |
inherit*. |
32 |
|
33 |
-- |
34 |
Best regards, |
35 |
Michał Górny |