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