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'. 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/>
pgpu4Yct19FyE.pgp
Description: OpenPGP digital signature
