Re: [gentoo-dev] RFC: Eclasses and EAPI

[Rich Freeman]

On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz  wrote:
> Kristian Fiskerstrand  writes:
>> inherited eclasses. having a whitelist in place and die if eclass is not
>> updated to handle it solves it.
>>
>> Thoughts? comments? cookies? threats?
>
> Wouldn't a blacklist be more practical than a whitelist?
>
>   root# cat /usr/portage/profiles/eclass.eapi.mask
>
>   fooutils.eclass >=6
>
> The problem seems infrequent enough that a blacklist is sufficient, like
> all the *.mask files in /usr/portage/profiles.
>
> The whitelist places a large testing burden on eclass authors on each
> EAPI bump, where 99% of the time there won't be any issue to fix.

A few things:

1.  Your syntax assumes that EAPIs are ordered (I'll let the
mathematicians go on about set theory).  Nothing about PMS requires
this, the next one could be "2B," or "Fred," or "."  (Apologies on
the last one if it doesn't come through, as I have no idea how UTF-8
safe email actually is.)  I don't think it is likely, but I know
somebody else will point it out if I don't.
2.  I think that requiring eclasses to be reviewed before use on a new
EAPI is a feature, and not a bug.  It is a trivial update if it is
fine, and depending on the nature of the eclass it might be trivial to
determine if there will be a problem.  If it isn't trivial to
determine if there is a problem, it is probably even more important
that it be reviewed.
3.  The whole problem driving this is people using EAPIs with eclasses
without realizing they fail in subtle ways.  If they're unmaintained,
this is even more likely to happen, and all the more reason to expose
the problem.  It is better to expose problems during design than at
runtime.
4.  EAPIs seem to come out about every other year right now.  Is it
really THAT hard to keep up with them?  And eclasses which fall behind
should probably be candidates for treecleaning anyway.

-- 
Rich

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Erik Mackdanz]

Kristian Fiskerstrand  writes:
> inherited eclasses. having a whitelist in place and die if eclass is not
> updated to handle it solves it.
>
> Thoughts? comments? cookies? threats?

Wouldn't a blacklist be more practical than a whitelist?

  root# cat /usr/portage/profiles/eclass.eapi.mask

  fooutils.eclass >=6

The problem seems infrequent enough that a blacklist is sufficient, like
all the *.mask files in /usr/portage/profiles.

The whitelist places a large testing burden on eclass authors on each
EAPI bump, where 99% of the time there won't be any issue to fix.

Erik

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Michał Górny]

On Tue, 6 Sep 2016 09:19:42 -0400
Rich Freeman  wrote:

> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  wrote:
> >
> > I believe you're overthinking it, if we make it a guideline to include a
> > section of the eclass (as many already have) that does e.g (take this
> > for example purposes) there is no EAPI/PMS change needed
> > case "${EAPI:-0}" in
> > 4|5|6)
> > ;;
> >  *) die "EAPI=${EAPI} is not supported" ;;
> >  
> 
> I think the question becomes then what do we do about eclasses that
> don't follow the guideline?
> 
> With a PMS change we can in the future enforce that the eclass
> explicitly declare support by making it break by default if nothing is
> done.  With the approach above an eclass works with any EAPI by
> default as far as PMS is concerned, and we rely on eclasses to
> self-destruct when they're supposed to.

PMS is there to solve the technical problem of compatibility between
ebuilds and package managers, and you sound like you want to use it to
solve a social problem.

If we can agree on a policy adding a check like this, then enforcing it
should be a minor problem. Of course, it can become a problem with
the usual developers who know better and are going to refuse to comply
but again, this is a social problem.

Adding additional layer of complexity and enforcing the policy via PMS
sounds like you want to enforce the policy one level higher, so that
the developers would find it harder to reject it. Does that really
sound like the way to solve the problem?

-- 
Best regards,
Michał Górny



pgpiFCCwDk2_v.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 03:38 PM, M. J. Everitt wrote:
> On 06/09/16 14:35, Kristian Fiskerstrand wrote:
>> On 09/06/2016 03:19 PM, Rich Freeman wrote:
>>> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  
>>> wrote:
 I believe you're overthinking it, if we make it a guideline to include a
 section of the eclass (as many already have) that does e.g (take this
 for example purposes) there is no EAPI/PMS change needed
 case "${EAPI:-0}" in
 4|5|6)
 ;;
  *) die "EAPI=${EAPI} is not supported" ;;

>>> I think the question becomes then what do we do about eclasses that
>>> don't follow the guideline?
>> A natural step might be QA team involved in such cases?
>>
> Did you just volunteer to join QA there, Kristian ?! ;)
> 

hehe :) If they want me to contribute there they can ask. I'm certainly
not fundamentally opposed, but I believe they overall have a good
project going already so I'm allocating my (sadly resource constrained)
Gentoo-time elsewhere.

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 03:19 PM, Rich Freeman wrote:
> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  wrote:
>>
>> I believe you're overthinking it, if we make it a guideline to include a
>> section of the eclass (as many already have) that does e.g (take this
>> for example purposes) there is no EAPI/PMS change needed
>> case "${EAPI:-0}" in
>> 4|5|6)
>> ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>>
> 
> I think the question becomes then what do we do about eclasses that
> don't follow the guideline?

A natural step might be QA team involved in such cases?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 12:44 PM, Kent Fredric wrote:
> On Mon, 5 Sep 2016 15:03:36 +0200
> Michał Górny  wrote:
> 
>> On Fri, 2 Sep 2016 18:13:20 +0200
>> Kristian Fiskerstrand  wrote:
>>
>>> I'm wondering whether it wouldn't make sense to require eclasses (or
>>> strongly encourage) to include an explicit list of EAPIs it has been
>>> tested for in order to ease testing when introducing new EAPIs.
>>>
>>> We have seen some issues already with EAPI6 bump related to get_libdir
>>> and people updating EAPI in ebuild without properly testing the
>>> inherited eclasses. having a whitelist in place and die if eclass is not
>>> updated to handle it solves it.
>>>
>>> Thoughts? comments? cookies? threats?  
>>
>> +1. Because:
>>
>> 1. it makes it possible to change API safely with EAPI bump, including
>> major refactorings,
>>
>> 2. it makes it possible for the eclass maintainer to confirm that
>> the eclass is correctly ported to new EAPI, rather than some random
>> developer with poor knowledge of eclass assuming it works fine,
>>
>> 3. it makes it possible to ban the eclass in a new EAPI to more
>> effectively phase it out.
>>
>> This only reminds me of the cases when eclasses weren't calling
>> eapply_user in EAPI 6 and caused ebuilds to fail. Because someone
>> assumed that if his ebuild works in EAPI 6, then the eclass is
>> certainly correct.
>>
> 
> My only question is how we enforce it.
> 
> Given that eclasses are themselves without EAPI, and relying on this
> check existing in PMS would require such a feature defined in a future EAPI
> 
> I suspect for the forseeable future we're going to need to double our effort,
> having a whitelist that is only able to be interpreted by PMS clients that 
> implement
> EAPI7, and then the traditional logic for Pre-EAPI7.
> 

I believe you're overthinking it, if we make it a guideline to include a
section of the eclass (as many already have) that does e.g (take this
for example purposes) there is no EAPI/PMS change needed
case "${EAPI:-0}" in
4|5|6)
;;
 *) die "EAPI=${EAPI} is not supported" ;;



-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kent Fredric]

On Mon, 5 Sep 2016 15:03:36 +0200
Michał Górny  wrote:

> On Fri, 2 Sep 2016 18:13:20 +0200
> Kristian Fiskerstrand  wrote:
> 
> > I'm wondering whether it wouldn't make sense to require eclasses (or
> > strongly encourage) to include an explicit list of EAPIs it has been
> > tested for in order to ease testing when introducing new EAPIs.
> > 
> > We have seen some issues already with EAPI6 bump related to get_libdir
> > and people updating EAPI in ebuild without properly testing the
> > inherited eclasses. having a whitelist in place and die if eclass is not
> > updated to handle it solves it.
> > 
> > Thoughts? comments? cookies? threats?  
> 
> +1. Because:
> 
> 1. it makes it possible to change API safely with EAPI bump, including
> major refactorings,
> 
> 2. it makes it possible for the eclass maintainer to confirm that
> the eclass is correctly ported to new EAPI, rather than some random
> developer with poor knowledge of eclass assuming it works fine,
> 
> 3. it makes it possible to ban the eclass in a new EAPI to more
> effectively phase it out.
> 
> This only reminds me of the cases when eclasses weren't calling
> eapply_user in EAPI 6 and caused ebuilds to fail. Because someone
> assumed that if his ebuild works in EAPI 6, then the eclass is
> certainly correct.
> 

My only question is how we enforce it.

Given that eclasses are themselves without EAPI, and relying on this
check existing in PMS would require such a feature defined in a future EAPI

I suspect for the forseeable future we're going to need to double our effort,
having a whitelist that is only able to be interpreted by PMS clients that 
implement
EAPI7, and then the traditional logic for Pre-EAPI7.

And then when EAPI7 rolls around, all the eclasses without the EAPI7 magic hints
will be assumed "not to support EAPI7+"

And to support EAPI7, you must declare your support for the other EAPIs too.

Though I never figured it was a question of "should we", we rather should.

Only a question of "How do we do it"


pgpHuUuISyqg1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Alexis Ballier]

On Mon, 5 Sep 2016 10:45:30 -0400
Mike Gilbert  wrote:

> On Mon, Sep 5, 2016 at 5:20 AM, Alexis Ballier 
> wrote:
> > On Fri, 2 Sep 2016 19:19:16 +0200
> > Kristian Fiskerstrand  wrote:
> >  
> >> On 09/02/2016 07:17 PM, Rich Freeman wrote:  
> >> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> >> >  wrote:  
> >> >> On Fri, 2 Sep 2016 18:13:20 +0200
> >> >> Kristian Fiskerstrand  wrote:
> >> >>  
> >> >>> Hi Devs,
> >> >>>
> >> >>> I'm wondering whether it wouldn't make sense to require
> >> >>> eclasses (or strongly encourage) to include an explicit list
> >> >>> of EAPIs it has been tested for in order to ease testing when
> >> >>> introducing new EAPIs.
> >> >>>
> >> >>> We have seen some issues already with EAPI6 bump related to
> >> >>> get_libdir and people updating EAPI in ebuild without properly
> >> >>> testing the inherited eclasses. having a whitelist in place and
> >> >>> die if eclass is not updated to handle it solves it.
> >> >>>
> >> >>> Thoughts? comments? cookies? threats?
> >> >>>  
> >> >>
> >> >> Never liked to wait for a whole eclass update for a new eapi
> >> >> when I only use a couple functions from it that I have tested
> >> >> when updating an ebuild.
> >> >>  
> >> >
> >> > I think the idea is a sound one though.  And there is no reason
> >> > it couldn't be tweaked to give the option to set it at the
> >> > function level and not the eclass level.  This is also an
> >> > argument for simplifying eclasses when it makes sense (I realize
> >> > this will never be 100%).  
> >>
> >> If specific functions can be useful there is also a case to be made
> >> for refactoring of the code
> >>  
> >
> >
> > Well, let's say we have an eapi that introduces usedeps and
> > src_configure. Let's say we have an ebuild with a few
> > built_with_use || die calls that could benefit from usedeps. Let's
> > call this ebuild vlc. Let's say this ebuild inherits an eclass for
> > updating the icon cache and redefines all other ebuild phases.
> > Let's call this eclass gnome2. Let's assume this eclass is widely
> > used by tens of packages that do actually use the exported
> > functions from it. It makes a lot of sense to ban this new eapi in
> > this eclass until it is ported. However, porting it takes months
> > and we are stick with those built_with_use || die calls.
> >
> > Of course, the best solution is to port the eclass. The second
> > option is to drop the inherit from the ebuild and call the relevant
> > functions by defining ebuild phases. This duplicates a bit of code
> > but works well. However, it seems to me it is more practical to
> > have an eclass not dying and letting ebuild writers deal with their
> > crap if something goes wrong.
> >  
> 
> I think this is a good argument for keeping utility functions and
> phase functions in separate eclasses, regardless of EAPI gating.


Probably. But this is not an argument at all: it is just an example of
when what is proposed is perfectly valid, for good reasons, but also
impractical. In the end, it depends where one wants to draw the line.

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Mike Gilbert]

On Mon, Sep 5, 2016 at 5:20 AM, Alexis Ballier  wrote:
> On Fri, 2 Sep 2016 19:19:16 +0200
> Kristian Fiskerstrand  wrote:
>
>> On 09/02/2016 07:17 PM, Rich Freeman wrote:
>> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
>> >  wrote:
>> >> On Fri, 2 Sep 2016 18:13:20 +0200
>> >> Kristian Fiskerstrand  wrote:
>> >>
>> >>> Hi Devs,
>> >>>
>> >>> I'm wondering whether it wouldn't make sense to require eclasses
>> >>> (or strongly encourage) to include an explicit list of EAPIs it
>> >>> has been tested for in order to ease testing when introducing new
>> >>> EAPIs.
>> >>>
>> >>> We have seen some issues already with EAPI6 bump related to
>> >>> get_libdir and people updating EAPI in ebuild without properly
>> >>> testing the inherited eclasses. having a whitelist in place and
>> >>> die if eclass is not updated to handle it solves it.
>> >>>
>> >>> Thoughts? comments? cookies? threats?
>> >>>
>> >>
>> >> Never liked to wait for a whole eclass update for a new eapi when I
>> >> only use a couple functions from it that I have tested when
>> >> updating an ebuild.
>> >>
>> >
>> > I think the idea is a sound one though.  And there is no reason it
>> > couldn't be tweaked to give the option to set it at the function
>> > level and not the eclass level.  This is also an argument for
>> > simplifying eclasses when it makes sense (I realize this will never
>> > be 100%).
>>
>> If specific functions can be useful there is also a case to be made
>> for refactoring of the code
>>
>
>
> Well, let's say we have an eapi that introduces usedeps and
> src_configure. Let's say we have an ebuild with a few built_with_use ||
> die calls that could benefit from usedeps. Let's call this ebuild vlc.
> Let's say this ebuild inherits an eclass for updating the icon cache
> and redefines all other ebuild phases. Let's call this eclass gnome2.
> Let's assume this eclass is widely used by tens of packages that do
> actually use the exported functions from it. It makes a lot of sense to
> ban this new eapi in this eclass until it is ported. However, porting
> it takes months and we are stick with those built_with_use || die calls.
>
> Of course, the best solution is to port the eclass. The second
> option is to drop the inherit from the ebuild and call the relevant
> functions by defining ebuild phases. This duplicates a bit of code but
> works well. However, it seems to me it is more practical to have an
> eclass not dying and letting ebuild writers deal with their crap if
> something goes wrong.
>

I think this is a good argument for keeping utility functions and
phase functions in separate eclasses, regardless of EAPI gating.

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Alexis Ballier]

On Mon, 5 Sep 2016 14:58:29 +0200
Michał Górny  wrote:

> On Mon, 5 Sep 2016 11:20:29 +0200
> Alexis Ballier  wrote:
> 
> > On Fri, 2 Sep 2016 19:19:16 +0200
> > Kristian Fiskerstrand  wrote:
> >   
> > > On 09/02/2016 07:17 PM, Rich Freeman wrote:
> > > > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> > > >  wrote:  
> > > >> On Fri, 2 Sep 2016 18:13:20 +0200
> > > >> Kristian Fiskerstrand  wrote:
> > > >>  
> > > >>> Hi Devs,
> > > >>>
> > > >>> I'm wondering whether it wouldn't make sense to require
> > > >>> eclasses (or strongly encourage) to include an explicit list
> > > >>> of EAPIs it has been tested for in order to ease testing when
> > > >>> introducing new EAPIs.
> > > >>>
> > > >>> We have seen some issues already with EAPI6 bump related to
> > > >>> get_libdir and people updating EAPI in ebuild without properly
> > > >>> testing the inherited eclasses. having a whitelist in place
> > > >>> and die if eclass is not updated to handle it solves it.
> > > >>>
> > > >>> Thoughts? comments? cookies? threats?
> > > >>>  
> > > >>
> > > >> Never liked to wait for a whole eclass update for a new eapi
> > > >> when I only use a couple functions from it that I have tested
> > > >> when updating an ebuild.
> > > >>  
> > > > 
> > > > I think the idea is a sound one though.  And there is no reason
> > > > it couldn't be tweaked to give the option to set it at the
> > > > function level and not the eclass level.  This is also an
> > > > argument for simplifying eclasses when it makes sense (I
> > > > realize this will never be 100%). 
> > > 
> > > If specific functions can be useful there is also a case to be
> > > made for refactoring of the code  
> > 
> > Well, let's say we have an eapi that introduces usedeps and
> > src_configure. Let's say we have an ebuild with a few
> > built_with_use || die calls that could benefit from usedeps. Let's
> > call this ebuild vlc. Let's say this ebuild inherits an eclass for
> > updating the icon cache and redefines all other ebuild phases.
> > Let's call this eclass gnome2. Let's assume this eclass is widely
> > used by tens of packages that do actually use the exported
> > functions from it. It makes a lot of sense to ban this new eapi in
> > this eclass until it is ported. However, porting it takes months
> > and we are stick with those built_with_use || die calls.
> > 
> > Of course, the best solution is to port the eclass. The second
> > option is to drop the inherit from the ebuild and call the relevant
> > functions by defining ebuild phases. This duplicates a bit of code
> > but works well. However, it seems to me it is more practical to
> > have an eclass not dying and letting ebuild writers deal with their
> > crap if something goes wrong.  
> 
> That's the worst argument I've heard for a long time.
> 
> It could be pretty much summarized as 'let's commit crap and hope it
> will work; worst case, things will go horribly kaboom on users'.

Then you've not understood a single bit of what was written.

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Michał Górny]

On Fri, 2 Sep 2016 18:13:20 +0200
Kristian Fiskerstrand  wrote:

> I'm wondering whether it wouldn't make sense to require eclasses (or
> strongly encourage) to include an explicit list of EAPIs it has been
> tested for in order to ease testing when introducing new EAPIs.
> 
> We have seen some issues already with EAPI6 bump related to get_libdir
> and people updating EAPI in ebuild without properly testing the
> inherited eclasses. having a whitelist in place and die if eclass is not
> updated to handle it solves it.
> 
> Thoughts? comments? cookies? threats?

+1. Because:

1. it makes it possible to change API safely with EAPI bump, including
major refactorings,

2. it makes it possible for the eclass maintainer to confirm that
the eclass is correctly ported to new EAPI, rather than some random
developer with poor knowledge of eclass assuming it works fine,

3. it makes it possible to ban the eclass in a new EAPI to more
effectively phase it out.

This only reminds me of the cases when eclasses weren't calling
eapply_user in EAPI 6 and caused ebuilds to fail. Because someone
assumed that if his ebuild works in EAPI 6, then the eclass is
certainly correct.

-- 
Best regards,
Michał Górny



pgpM9h5Kp2bm4.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Michał Górny]

On Mon, 5 Sep 2016 11:20:29 +0200
Alexis Ballier  wrote:

> On Fri, 2 Sep 2016 19:19:16 +0200
> Kristian Fiskerstrand  wrote:
> 
> > On 09/02/2016 07:17 PM, Rich Freeman wrote:  
> > > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> > >  wrote:
> > >> On Fri, 2 Sep 2016 18:13:20 +0200
> > >> Kristian Fiskerstrand  wrote:
> > >>
> > >>> Hi Devs,
> > >>>
> > >>> I'm wondering whether it wouldn't make sense to require eclasses
> > >>> (or strongly encourage) to include an explicit list of EAPIs it
> > >>> has been tested for in order to ease testing when introducing new
> > >>> EAPIs.
> > >>>
> > >>> We have seen some issues already with EAPI6 bump related to
> > >>> get_libdir and people updating EAPI in ebuild without properly
> > >>> testing the inherited eclasses. having a whitelist in place and
> > >>> die if eclass is not updated to handle it solves it.
> > >>>
> > >>> Thoughts? comments? cookies? threats?
> > >>>
> > >>
> > >> Never liked to wait for a whole eclass update for a new eapi when I
> > >> only use a couple functions from it that I have tested when
> > >> updating an ebuild.
> > >>
> > > 
> > > I think the idea is a sound one though.  And there is no reason it
> > > couldn't be tweaked to give the option to set it at the function
> > > level and not the eclass level.  This is also an argument for
> > > simplifying eclasses when it makes sense (I realize this will never
> > > be 100%).   
> > 
> > If specific functions can be useful there is also a case to be made
> > for refactoring of the code
> 
> Well, let's say we have an eapi that introduces usedeps and
> src_configure. Let's say we have an ebuild with a few built_with_use ||
> die calls that could benefit from usedeps. Let's call this ebuild vlc.
> Let's say this ebuild inherits an eclass for updating the icon cache
> and redefines all other ebuild phases. Let's call this eclass gnome2.
> Let's assume this eclass is widely used by tens of packages that do
> actually use the exported functions from it. It makes a lot of sense to
> ban this new eapi in this eclass until it is ported. However, porting
> it takes months and we are stick with those built_with_use || die calls.
> 
> Of course, the best solution is to port the eclass. The second
> option is to drop the inherit from the ebuild and call the relevant
> functions by defining ebuild phases. This duplicates a bit of code but
> works well. However, it seems to me it is more practical to have an
> eclass not dying and letting ebuild writers deal with their crap if
> something goes wrong.

That's the worst argument I've heard for a long time.

It could be pretty much summarized as 'let's commit crap and hope it
will work; worst case, things will go horribly kaboom on users'.
And now imagine some of those ebuilds are stabilized before the eclass
finally moves on.

-- 
Best regards,
Michał Górny



pgpu4Yct19FyE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Alexis Ballier]

On Fri, 2 Sep 2016 19:19:16 +0200
Kristian Fiskerstrand  wrote:

> On 09/02/2016 07:17 PM, Rich Freeman wrote:
> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> >  wrote:  
> >> On Fri, 2 Sep 2016 18:13:20 +0200
> >> Kristian Fiskerstrand  wrote:
> >>  
> >>> Hi Devs,
> >>>
> >>> I'm wondering whether it wouldn't make sense to require eclasses
> >>> (or strongly encourage) to include an explicit list of EAPIs it
> >>> has been tested for in order to ease testing when introducing new
> >>> EAPIs.
> >>>
> >>> We have seen some issues already with EAPI6 bump related to
> >>> get_libdir and people updating EAPI in ebuild without properly
> >>> testing the inherited eclasses. having a whitelist in place and
> >>> die if eclass is not updated to handle it solves it.
> >>>
> >>> Thoughts? comments? cookies? threats?
> >>>  
> >>
> >> Never liked to wait for a whole eclass update for a new eapi when I
> >> only use a couple functions from it that I have tested when
> >> updating an ebuild.
> >>  
> > 
> > I think the idea is a sound one though.  And there is no reason it
> > couldn't be tweaked to give the option to set it at the function
> > level and not the eclass level.  This is also an argument for
> > simplifying eclasses when it makes sense (I realize this will never
> > be 100%). 
> 
> If specific functions can be useful there is also a case to be made
> for refactoring of the code
> 


Well, let's say we have an eapi that introduces usedeps and
src_configure. Let's say we have an ebuild with a few built_with_use ||
die calls that could benefit from usedeps. Let's call this ebuild vlc.
Let's say this ebuild inherits an eclass for updating the icon cache
and redefines all other ebuild phases. Let's call this eclass gnome2.
Let's assume this eclass is widely used by tens of packages that do
actually use the exported functions from it. It makes a lot of sense to
ban this new eapi in this eclass until it is ported. However, porting
it takes months and we are stick with those built_with_use || die calls.

Of course, the best solution is to port the eclass. The second
option is to drop the inherit from the ebuild and call the relevant
functions by defining ebuild phases. This duplicates a bit of code but
works well. However, it seems to me it is more practical to have an
eclass not dying and letting ebuild writers deal with their crap if
something goes wrong.

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/02/2016 07:17 PM, Rich Freeman wrote:
> On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier  wrote:
>> On Fri, 2 Sep 2016 18:13:20 +0200
>> Kristian Fiskerstrand  wrote:
>>
>>> Hi Devs,
>>>
>>> I'm wondering whether it wouldn't make sense to require eclasses (or
>>> strongly encourage) to include an explicit list of EAPIs it has been
>>> tested for in order to ease testing when introducing new EAPIs.
>>>
>>> We have seen some issues already with EAPI6 bump related to get_libdir
>>> and people updating EAPI in ebuild without properly testing the
>>> inherited eclasses. having a whitelist in place and die if eclass is
>>> not updated to handle it solves it.
>>>
>>> Thoughts? comments? cookies? threats?
>>>
>>
>> Never liked to wait for a whole eclass update for a new eapi when I
>> only use a couple functions from it that I have tested when updating an
>> ebuild.
>>
> 
> I think the idea is a sound one though.  And there is no reason it
> couldn't be tweaked to give the option to set it at the function level
> and not the eclass level.  This is also an argument for simplifying
> eclasses when it makes sense (I realize this will never be 100%).
> 

If specific functions can be useful there is also a case to be made for
refactoring of the code

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Alexis Ballier]

On Fri, 2 Sep 2016 18:13:20 +0200
Kristian Fiskerstrand  wrote:

> Hi Devs,
> 
> I'm wondering whether it wouldn't make sense to require eclasses (or
> strongly encourage) to include an explicit list of EAPIs it has been
> tested for in order to ease testing when introducing new EAPIs.
> 
> We have seen some issues already with EAPI6 bump related to get_libdir
> and people updating EAPI in ebuild without properly testing the
> inherited eclasses. having a whitelist in place and die if eclass is
> not updated to handle it solves it.
> 
> Thoughts? comments? cookies? threats?
> 

Never liked to wait for a whole eclass update for a new eapi when I
only use a couple functions from it that I have tested when updating an
ebuild.