On Mon, 5 Sep 2016 15:03:36 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> On Fri, 2 Sep 2016 18:13:20 +0200 > Kristian Fiskerstrand <k...@gentoo.org> wrote: > > > 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? > > +1. Because: > > 1. it makes it possible to change API safely with EAPI bump, including > major refactorings, > > 2. it makes it possible for the eclass maintainer to confirm that > the eclass is correctly ported to new EAPI, rather than some random > developer with poor knowledge of eclass assuming it works fine, > > 3. it makes it possible to ban the eclass in a new EAPI to more > effectively phase it out. > > This only reminds me of the cases when eclasses weren't calling > eapply_user in EAPI 6 and caused ebuilds to fail. Because someone > assumed that if his ebuild works in EAPI 6, then the eclass is > certainly correct. > My only question is how we enforce it. Given that eclasses are themselves without EAPI, and relying on this check existing in PMS would require such a feature defined in a future EAPI I suspect for the forseeable future we're going to need to double our effort, having a whitelist that is only able to be interpreted by PMS clients that implement EAPI7, and then the traditional logic for Pre-EAPI7. And then when EAPI7 rolls around, all the eclasses without the EAPI7 magic hints will be assumed "not to support EAPI7+" And to support EAPI7, you must declare your support for the other EAPIs too. Though I never figured it was a question of "should we", we rather should. Only a question of "How do we do it"
pgpHuUuISyqg1.pgp
Description: OpenPGP digital signature
