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.
