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