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 791151382C5 for ; Tue, 6 Mar 2018 05:57:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12E79E0909; Tue, 6 Mar 2018 05:56:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B5493E08F4 for ; Tue, 6 Mar 2018 05:56:57 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id A3A39335C5F for ; Tue, 6 Mar 2018 05:56:55 +0000 (UTC) Date: Tue, 6 Mar 2018 18:56:13 +1300 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Is removing old EAPIs worth the churn? Message-ID: <20180306185613.5a1bde59@katipo2.lan> In-Reply-To: References: Organization: Gentoo X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; 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_/SgxFq7wYF0nYE6qhdpXQ94C"; protocol="application/pgp-signature" X-Archives-Salt: cdf7facb-c611-44cb-8c9f-613ecd87c744 X-Archives-Hash: 20f236605b3da7a9332a7602d7850c35 --Sig_/SgxFq7wYF0nYE6qhdpXQ94C Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 5 Mar 2018 17:52:54 -0800 Matt Turner wrote: > EAPI 2 removal bug: https://bugs.gentoo.org/648050 >=20 > It seems like tons of churn to update old stable ebuilds to a new > EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for > example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise > functionally identical. Now asking arch teams to retest and > restabilize. Multiply by 100 or more. >=20 > In the end we might get to delete some code from portage or an eclass? > Does this seem worth it? >=20 New EAPI's don't just do nothing, some for example, add more power to users. EAPI6 is an especially significant example due to eapply_user becoming standardized. And with Perl packages at least, incrementing EAPI results in actual changes driven by the eclass: - Changes the names of various control variables - Makes perl tests on by default, and parallel by default ( previously required opt-in ) - Disables the legacy code path that kills the '.packlist' files, which are actually useful to some tools, and was the wrong place to kill those files in the first place. Incrementing EAPI also functions as an indicator that legacy approaches and interfaces are moved away from, which can also signify an improvement in ebuild quality. In short, while it looks superficially useless, I'd argue that there's a lot of nuanced benefits. --Sig_/SgxFq7wYF0nYE6qhdpXQ94C Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAlqeLYsACgkQ6FQySxNm qCCgHxAAsy0v2o34md5hDIYTX8i2b/BeUWRHzA6XcuPkJC9rC+OD87JL6afZy649 f2Guct64t/q2xMmG8wSyEAgRvlM9Kw+fLJdDPuRCHE5XgjFI9FC3iLGrSIAg3J68 BvrFyt0ikCCxQ0B7ldlcLZXUqQq1p/6BusBYIWPHnNVwVkFVNvtcct30p8NBkSlQ U9pmjy3Zxks608iO0gIqlqPnc7V/xojFnvP/Hd3/cob85Y/drm/fky3xHzuVRhhb 1pzJJtORFMzgG60Je0YYGkmJEnwf4QmUNv+Gqcs1Ef+gQcNpna3e7eb13X4EtmYF G+K9bBvj1SCKzxDwxLmZwY3pucBcn+F6qh0M/DlMld8Zp4hmgm866zG7C9IL32i/ 0sKrwt6ZB2lYJygBc1s5MYQY9psXQ6C/0HPWv5RRfekifCSr8Kf+NMv2SkU6/7PU ym4SWMPZhdRub8JsLtWF5YuJlmUyQeJJXm2N91iRb76ISWyVBwHiJEqFvEFLVYxq hnLLDlg++KSq5XUqSDWW+U08cLZFlWTtTBzOZnS5oBqXRoaI3oVtysLX4NzYFqL2 l7POfSO/shl19V3oG9jdBxQpWbBPTZMgSr4y9fxEFm7U8oqc3wEh2ogHuGYgVhJC y/TErFEUqhsxt24aIwp8nCUe2rQPGeuI5V9A5Lq2JvSfXBfm57Y= =Bu9q -----END PGP SIGNATURE----- --Sig_/SgxFq7wYF0nYE6qhdpXQ94C--