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

[Alexis Ballier]

On Mon, 5 Sep 2016 10:45:30 -0400
Mike Gilbert <floppym@g.o> wrote:

> On Mon, Sep 5, 2016 at 5:20 AM, 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.
> >
>
> 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.