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

[Michał Górny]

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'.
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/>