From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0629A138330 for ; Tue, 6 Sep 2016 10:45:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 667D521C03E; Tue, 6 Sep 2016 10:45:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5321EE0818 for ; Tue, 6 Sep 2016 10:45:45 +0000 (UTC) Received: from katipo2.lan (unknown [IPv6:2406:e001:1:d01:c2f8:daff:fe83:ed01]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 758C63407D0 for ; Tue, 6 Sep 2016 10:45:43 +0000 (UTC) Date: Tue, 6 Sep 2016 22:44:59 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Eclasses and EAPI Message-ID: <20160906224459.58062ef6@katipo2.lan> In-Reply-To: <20160905150336.7f41a4c1.mgorny@gentoo.org> References: <20160905150336.7f41a4c1.mgorny@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/U/Q66jd/h5T5wmqPCk7xqQG"; protocol="application/pgp-signature" X-Archives-Salt: c79f61ec-a9b0-4be5-9ea7-a570dae24b17 X-Archives-Hash: 48ae393a3d677c2b4cc07dfcd0fc7d35 --Sig_/U/Q66jd/h5T5wmqPCk7xqQG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 5 Sep 2016 15:03:36 +0200 Micha=C5=82 G=C3=B3rny wrote: > On Fri, 2 Sep 2016 18:13:20 +0200 > Kristian Fiskerstrand wrote: >=20 > > 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. > >=20 > > 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. > >=20 > > Thoughts? comments? cookies? threats? =20 >=20 > +1. Because: >=20 > 1. it makes it possible to change API safely with EAPI bump, including > major refactorings, >=20 > 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, >=20 > 3. it makes it possible to ban the eclass in a new EAPI to more > effectively phase it out. >=20 > 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. >=20 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 effor= t, 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" --Sig_/U/Q66jd/h5T5wmqPCk7xqQG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXzp5IAAoJEOhUMksTZqggYXMP/jt1t0zFKTTuSVaYJszJDHgO 9RA9EOTl01JeD3LLvresJ1wj8/L9ZUHSqOwyEUYMNb+6hOiyYEK35B4qNSUCSCPe BjmbJwT3A1ZzEN2tJcBrSIyNYTlbwdLm7jPaG47SZApnDJCzSC1KUoFEfkUcD1pC c9cGqxuASZQkUBD5Zhnit1vWjByeLBMqh8YAfA+v+iFLZrdU7ZJ/IUtdGeG2qkPj BWbvL51i8EwoZsJS20EjSuFTg+xUADrYgljdIWA/ZAOIOtovYdbnEPRFyBK+540Q OBSXivq9jkgXxlwO6FlR10KlajdIcAdLe/Accx99pjJINzJMR+CyGZzRkzMmJkhr 3jdXOXExeDopwSIXwCnDk+5BXnX8ZKe/rKKPY3KIlO0dhtLnXZ2VnJHzICJbUjk0 snyZoQjuyoCPW3LZQYhBjaz67e925Py6JnSZPe1qIN+xgr8eAzk2krqd+yRGJzMY TcGtVRh7swuiEmbzTHC8CYGiyKbBEjhPOlQ8o4EaocxvuIqu2bcMRrGKrRwy0vQs 58V513SXAuOBtLnHER1xoF9rXr3EE6NC+gs+L7OozNfBmP+m8XgXUr8hTJ9D7N6Y ZNwHXaZ3IYlSYT+lC8WXA2bqXF6rikGMpDXt/AMwR8RiuHSRMtpxntkTGc64Cnx4 6267Z2bgRXj2YZ/YnZuL =Ifrs -----END PGP SIGNATURE----- --Sig_/U/Q66jd/h5T5wmqPCk7xqQG--