On Mon, 5 Sep 2016 14:58:29 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> On Mon, 5 Sep 2016 11:20:29 +0200 > 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. > > 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.
