[gentoo-dev] RFC: Eclasses and EAPI

[gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]

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?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Alexis Ballier]

On Fri, 2 Sep 2016 18:13:20 +0200
Kristian Fiskerstrand <k_f@gentoo.org> 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.

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

[Rich Freeman]

On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Fri, 2 Sep 2016 18:13:20 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> 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%).

-- 
Rich

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1482 bytes --]

On 09/02/2016 07:17 PM, Rich Freeman wrote:
> On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier <aballier@gentoo.org> wrote:
>> On Fri, 2 Sep 2016 18:13:20 +0200
>> Kristian Fiskerstrand <k_f@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Alexis Ballier]

On Fri, 2 Sep 2016 19:19:16 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 09/02/2016 07:17 PM, Rich Freeman wrote:
> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> > <aballier@gentoo.org> wrote:  
> >> On Fri, 2 Sep 2016 18:13:20 +0200
> >> Kristian Fiskerstrand <k_f@gentoo.org> 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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

On Mon, 5 Sep 2016 11:20:29 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 2 Sep 2016 19:19:16 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> 
> > On 09/02/2016 07:17 PM, Rich Freeman wrote:  
> > > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> > > <aballier@gentoo.org> wrote:    
> > >> On Fri, 2 Sep 2016 18:13:20 +0200
> > >> Kristian Fiskerstrand <k_f@gentoo.org> 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
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Fri, 2 Sep 2016 18:13:20 +0200
Kristian Fiskerstrand <k_f@gentoo.org> 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
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Alexis Ballier]

On Mon, 5 Sep 2016 14:58:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 5 Sep 2016 11:20:29 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Fri, 2 Sep 2016 19:19:16 +0200
> > Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> >   
> > > On 09/02/2016 07:17 PM, Rich Freeman wrote:    
> > > > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> > > > <aballier@gentoo.org> wrote:      
> > > >> On Fri, 2 Sep 2016 18:13:20 +0200
> > > >> Kristian Fiskerstrand <k_f@gentoo.org> 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

[Mike Gilbert]

On Mon, Sep 5, 2016 at 5:20 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Fri, 2 Sep 2016 19:19:16 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
>> On 09/02/2016 07:17 PM, Rich Freeman wrote:
>> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
>> > <aballier@gentoo.org> wrote:
>> >> On Fri, 2 Sep 2016 18:13:20 +0200
>> >> Kristian Fiskerstrand <k_f@gentoo.org> 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 10:45:30 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Mon, Sep 5, 2016 at 5:20 AM, Alexis Ballier <aballier@gentoo.org>
> wrote:
> > On Fri, 2 Sep 2016 19:19:16 +0200
> > Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> >  
> >> On 09/02/2016 07:17 PM, Rich Freeman wrote:  
> >> > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
> >> > <aballier@gentoo.org> wrote:  
> >> >> On Fri, 2 Sep 2016 18:13:20 +0200
> >> >> Kristian Fiskerstrand <k_f@gentoo.org> 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.

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

[Duncan]

Alexis Ballier posted on Mon, 05 Sep 2016 15:58:54 +0200 as excerpted:

> On Mon, 5 Sep 2016 14:58:29 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:
> 
>> On Mon, 5 Sep 2016 11:20:29 +0200 Alexis Ballier <aballier@gentoo.org>
>> wrote:
>> 
>> > On Fri, 2 Sep 2016 19:19:16 +0200 Kristian Fiskerstrand
>> > <k_f@gentoo.org> wrote:
>> >   
>> > > On 09/02/2016 07:17 PM, Rich Freeman wrote:
>> > > > On Fri, Sep 2, 2016 at 12:53 PM, Alexis Ballier
>> > > > <aballier@gentoo.org> wrote:
>> > > >> On Fri, 2 Sep 2016 18:13:20 +0200 Kristian Fiskerstrand
>> > > >> <k_f@gentoo.org> 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.

PMFJI, but either I'm not understanding either, or mgorny did understand, 
but is looking at it from a different perspective, that being the eclass 
maintainer's perspective, and thus seeing an angle/problem you didn't 
cover in your example.

Here's the problem.  If an eclass hasn't been ported to a new EAPI, then 
it's reasonable for the eclass maintainer to assume that no ebuilds 
inheriting it should have been ported to that EAPI either.  Now if your 
ebuild inherits that eclass before the porting, and claims the new EAPI, 
it may be tested and work just fine at first, possibly even with that 
ebuild being stabilized.

But the maintainer still hasn't ported the eclass to the new EAPI and is 
working on porting under the assumption that no ebuilds inheriting it 
will have been ported either, so the maintainer is free to implement the 
new EAPI as desired, taking the opportunity to kill some cruft, etc, by 
not exporting it to the new EAPI, because any ebuild using that eclass 
porting will, from the eclass maintainer's perspective, only be ported 
after the eclass itself is.

So now the eclass maintainer kills a function or two as from his 
perspective they don't make sense in the new EAPI, still assuming no 
ebuild inheriting the eclass uses the new EAPI, and that tested and 
possibly stable ebuild that prematurely upgraded to the new EAPI before 
that eclass it inherited did, suddenly goes BOOM, because that function 
that was used in the ebuild suddenly disappears!

Which was perfectly logical for the eclass maintainer to do, since he 
logically assumed that no ebuild inheriting that eclass would be EAPI-
upgraded before the eclass itself was, making the conditional removal for 
only that new EAPI perfectly fine since from his perspective any ebuilds 
inheriting that eclass and porting to the new EAPI could simply deal with 
the missing function when they ported to the new EAPI themselves.

Which of course is yet another reason to hard-code the eclass logic to 
die on any EAPI it isn't known to work with, since that will prevent the 
problem in the first place, because if the ebuild tried to jump the gun 
then, it would have immediately died and never would have passed testing, 
let alone possibly made it to stable, in the first place.

Did I get that correct, mgorny, or am I too not understanding, aballier?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Alexis Ballier]

On Tue, 6 Sep 2016 02:50:51 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> PMFJI, but either I'm not understanding either, or mgorny did
> understand, but is looking at it from a different perspective, that
> being the eclass maintainer's perspective, and thus seeing an
> angle/problem you didn't cover in your example.
> 
> Here's the problem.  If an eclass hasn't been ported to a new EAPI,
> then it's reasonable for the eclass maintainer to assume that no
> ebuilds inheriting it should have been ported to that EAPI either.


These cases can, of course, be marked as suggested in the initial post.
The example I wrote even broke in most cases when using the new EAPI,
providing an even more objective case pro-dying.
All are perfectly valid cases, but nothing shows it has to be the norm.

[...]
> Did I get that correct, mgorny, or am I too not understanding,
> aballier?


There is a huge gap between what you wrote and 'let's commit crap and
hope it will work; worst case, things will go horribly kaboom on
users'.

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

On Mon, 5 Sep 2016 15:03:36 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 2 Sep 2016 18:13:20 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> 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"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 2309 bytes --]

On 09/06/2016 12:44 PM, Kent Fredric wrote:
> On Mon, 5 Sep 2016 15:03:36 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
>> On Fri, 2 Sep 2016 18:13:20 +0200
>> Kristian Fiskerstrand <k_f@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Rich Freeman]

On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand <k_f@gentoo.org> 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.

I think this can be controlled if we're disciplined about catching
this in new eclasses.  We can do a one-time commit to all existing
eclasses to add this code somewhere if the maintainers do not add it.
That might involve either just having the eclasses abort on any EAPI
by default, on anything but the oldest supported EAPI, or just putting
in an acceptance of all existing EAPIs in which case we accept the
problem as far as the next PMS update but no further.  Obviously the
ideal solution is for eclasses to be properly maintained.

In general though I'm all for the proposal, and I tend to think that
it is best for an eclass to either support an EAPI or not, and not do
this per-function.  If that leads to refactoring so much the better.
I'm flexible on exactly how it gets implemented, but both eclass
maintainers and users should have a clear understanding of what
is/isn't supported.

-- 
Rich

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 772 bytes --]

On 09/06/2016 03:19 PM, Rich Freeman wrote:
> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand <k_f@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

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 <k_f@gentoo.org> 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 ?! ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]

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 <k_f@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Tue, 6 Sep 2016 09:19:42 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand <k_f@gentoo.org> 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
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Erik Mackdanz]

Kristian Fiskerstrand <k_f@gentoo.org> 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

[Rich Freeman]

On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz <stasibear@gentoo.org> wrote:
> Kristian Fiskerstrand <k_f@gentoo.org> 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