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.
