On Tue, 14 Aug 2012 21:56:38 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Tue, 14 Aug 2012 22:54:13 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > On Tue, 14 Aug 2012 21:45:56 +0100 > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Tue, 14 Aug 2012 11:44:49 +0200 > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > As some of you may have noticed, lately introduced 'double > > > > include preventions' have caused changes in effective phase > > > > functions in a few ebuilds. Also, often it is undesirable that > > > > change in inherits of an eclass may cause an undesired change > > > > of exported functions. > > > > > > The problem here is that eclasses aren't clearly split between > > > "utility" and "does stuff", so people are inheriting "does stuff" > > > eclasses to get utilities. The fix is to stop having stupidly huge > > > complicated eclasses; changing inherit behaviour is just > > > wallpapering over the gaping hole. > > > > Soo, how do you propose to handle bug 422533 without changing > > inherit behavior? > > We can't change inherit behaviour in EAPI 5 anyway since it's a global > scope function, so I was planning to ignore it and hope that by the > time EAPI 6 comes along, people will have learned not to write huge > eclasses that do more than one thing. And why? I believe we have quite a clean rule that *EAPI goes before inherit*. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
