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 08AB5138334 for ; Fri, 17 Aug 2018 13:16:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6FFD3E093A; Fri, 17 Aug 2018 13:16:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 1B3AAE0918 for ; Fri, 17 Aug 2018 13:16:03 +0000 (UTC) Received: from localhost (195-132-37-237.rev.numericable.fr [195.132.37.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 517D4335C29 for ; Fri, 17 Aug 2018 13:16:00 +0000 (UTC) Date: Fri, 17 Aug 2018 15:15:54 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] autotools.eclass and EAPI 7 Message-ID: <20180817151554.38938588@gentoo.org> In-Reply-To: <1534444616.2046.1.camel@gentoo.org> References: <506d4b17-9abd-b47d-d55a-d07073e4642b@gentoo.org> <1534444616.2046.1.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 604a9260-a209-4484-9a05-c516db76c1ea X-Archives-Hash: 714dae15966edf3e56431e3d14e1cd6b On Thu, 16 Aug 2018 21:36:56 +0300 Mart Raudsepp wrote: > =C3=9Chel kenal p=C3=A4eval, N, 16.08.2018 kell 14:27, kirjutas Brian Eva= ns: > > There are currently a handful of ebuilds using EAPI 7 and the > > autotools > > eclass. > >=20 > > I believe that this eclass should be reviewed for adding BDEPEND or > > having BDEPEND replace the DEPEND statement as the default action of > > the > > eclass. > >=20 > > Other items might be needed, but that's doubtful. > >=20 > > Someone please advise the best course of action and either do it or > > I will propose a patch based on the discussion. > > =20 >=20 > Could or did someone also check through all the other eclasses that > don't have any global EAPI compatibility checks? > For the future, maybe it's better to add such a check - just accepting > 0-7 or so, but unsure about all these custom EAPIs out there, might > force more eclass copying to some overlays. I don't really like that kind of checks: untested after usually small changes !=3D broken. IMHO a better solution could be to have council members review all eclasses prior to approving an eapi and either adding a comment why + a die when used with the not-yet-approved-eapi if the eclass requires changes or do nothing about it if it's fine. This has the double advantage to give council members first hands experience with an eapi before approving/voting it and ensures better migration when eapi is approved.