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

[Alexis Ballier]

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.