FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-14-2012, 09:44 AM
Michał Górny
 
Default Exporting phase funcs from direct inherits only

Hello,

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. To solve
these problems, we are proposing the following:


1. If an ebuild does not provide an explicit phase function, the phase
functions *directly exported* by *directly inherited* eclasses are used
to find a suitable default,

2. Thus, if an eclass inherits another eclass and expects the phase
functions of that eclass to be effective to the ebuild, it needs to
create its own phase function and export it.


This should make the ebuild behavior simpler to understand and saner.
It should also fix the forementioned issues, and allow us to make
the 'source eclasses only once'[1] proposal simpler.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=422533

--
Best regards,
Michał Górny
 
Old 08-14-2012, 07:46 PM
Zac Medico
 
Default Exporting phase funcs from direct inherits only

On 08/14/2012 02:44 AM, Michał Górny wrote:
> Hello,
>
> As some of you may have noticed, lately introduced 'double include
> preventions' have caused changes in effective phase functions in a few
> ebuilds.

Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
the ifndef block? The function implementations themselves can be inside
the ifndef block, since that only need to be sourced once.

> Also, often it is undesirable that change in inherits of
> an eclass may cause an undesired change of exported functions. To solve
> these problems, we are proposing the following:
>
>
> 1. If an ebuild does not provide an explicit phase function, the phase
> functions *directly exported* by *directly inherited* eclasses are used
> to find a suitable default,
>
> 2. Thus, if an eclass inherits another eclass and expects the phase
> functions of that eclass to be effective to the ebuild, it needs to
> create its own phase function and export it.
>
>
> This should make the ebuild behavior simpler to understand and saner.
> It should also fix the forementioned issues, and allow us to make
> the 'source eclasses only once'[1] proposal simpler.
>
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533

I'm not sure that your cure isn't worse than the disease.
--
Thanks,
Zac
 
Old 08-14-2012, 08:39 PM
Michał Górny
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 12:46:30 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/14/2012 02:44 AM, Michał Górny wrote:
> > Hello,
> >
> > As some of you may have noticed, lately introduced 'double include
> > preventions' have caused changes in effective phase functions in a
> > few ebuilds.
>
> Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
> the ifndef block? The function implementations themselves can be
> inside the ifndef block, since that only need to be sourced once.

Isn't that an awful kind of undefined behavior? We're already
on a slippery ground assuming that sourced data changes between
inherits. Assuming EXPORT_FUNCS will work some other ugly way is even
worse.

> > Also, often it is undesirable that change in inherits of
> > an eclass may cause an undesired change of exported functions. To
> > solve these problems, we are proposing the following:
> >
> >
> > 1. If an ebuild does not provide an explicit phase function, the
> > phase functions *directly exported* by *directly inherited*
> > eclasses are used to find a suitable default,
> >
> > 2. Thus, if an eclass inherits another eclass and expects the phase
> > functions of that eclass to be effective to the ebuild, it needs to
> > create its own phase function and export it.
> >
> >
> > This should make the ebuild behavior simpler to understand and
> > saner. It should also fix the forementioned issues, and allow us to
> > make the 'source eclasses only once'[1] proposal simpler.
> >
> > [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533
>
> I'm not sure that your cure isn't worse than the disease.

In any case, 2. should happen even now. Eclasses should be simple
and predictable, and debugging random failures isn't something nice.
Unless you're saying that adding phase functions overrides to
work-around failures which you don't even understand is a good solution.

--
Best regards,
Michał Górny
 
Old 08-14-2012, 08:45 PM
Ciaran McCreesh
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 11:44:49 +0200
Michał Górny <mgorny@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.

--
Ciaran McCreesh
 
Old 08-14-2012, 08:54 PM
Michał Górny
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 21:45:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 14 Aug 2012 11:44:49 +0200
> Michał Górny <mgorny@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?

--
Best regards,
Michał Górny
 
Old 08-14-2012, 08:56 PM
Ciaran McCreesh
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 22:54:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 14 Aug 2012 11:44:49 +0200
> > Michał Górny <mgorny@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.

--
Ciaran McCreesh
 
Old 08-14-2012, 09:01 PM
hasufell
 
Default Exporting phase funcs from direct inherits only

On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
>
> 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.
>

great idea, let's wait 5 years then
 
Old 08-14-2012, 09:09 PM
Zac Medico
 
Default Exporting phase funcs from direct inherits only

On 08/14/2012 01:54 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Tue, 14 Aug 2012 11:44:49 +0200
>> Michał Górny <mgorny@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.

Ciaran's assessment sounds pretty accurate to me.

> Soo, how do you propose to handle bug 422533 without changing inherit
> behavior?

Close it as WONTFIX. The ifndef thing that we're doing now seems like a
reasonable approach.
--
Thanks,
Zac
 
Old 08-14-2012, 09:09 PM
Michał Górny
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 21:56:38 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 14 Aug 2012 22:54:13 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 14 Aug 2012 11:44:49 +0200
> > > Michał Górny <mgorny@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
 
Old 08-14-2012, 09:11 PM
Ciaran McCreesh
 
Default Exporting phase funcs from direct inherits only

On Tue, 14 Aug 2012 23:09:55 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > 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*.

That rule will only start applying from EAPI 6 onwards.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 04:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org