On 09/06/2016 12:44 PM, Kent Fredric wrote: > 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. >
I believe you're overthinking it, if we make it a guideline to include a
section of the eclass (as many already have) that does e.g (take this
for example purposes) there is no EAPI/PMS change needed
case "${EAPI:-0}" in
4|5|6)
;;
*) die "EAPI=${EAPI} is not supported" ;;
--
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
