From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S5y0w-0000La-1e for garchives@archives.gentoo.org; Fri, 09 Mar 2012 11:29:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CE2F8E0764; Fri, 9 Mar 2012 11:29:26 +0000 (UTC) Received: from mx10.schiffbauer.net (mx10.schiffbauer.net [188.40.110.137]) by pigeon.gentoo.org (Postfix) with ESMTP id BC779E07EB for ; Fri, 9 Mar 2012 11:28:26 +0000 (UTC) Received: from cl-936.ham-02.de.sixxs.net ([2001:6f8:1c00:3a7::2]:48017 helo=lisa.schiffbauer.net) by mx10.schiffbauer.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S5xzb-0005C0-9s for gentoo-dev@lists.gentoo.org; Fri, 09 Mar 2012 12:28:25 +0100 Received: from mschiff by lisa.schiffbauer.net with local (Exim 4.77) (envelope-from ) id 1S5xzV-0004hP-EH for gentoo-dev@lists.gentoo.org; Fri, 09 Mar 2012 12:28:09 +0100 Date: Fri, 9 Mar 2012 12:28:09 +0100 From: Marc Schiffbauer To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds Message-ID: <20120309112808.GB16949@lisa.schiffbauer.lan> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> <20312.24445.451487.577826@a1i15.kph.uni-mainz.de> <20120308094222.GA21435@lisa.schiffbauer.lan> <4F58DEC1.7080003@gentoo.org> 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-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <4F58DEC1.7080003@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: by ClamAV (http://www.clamav.org) X-Spam-Score: -2.6 X-Spam-Level: -- X-Archives-Salt: b1a53f4b-16f8-4c09-9c3a-fd1450ac2b3c X-Archives-Hash: ed3db401c6f90c4b7033efccbe4c51b8 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Zac Medico schrieb am 08.03.12 um 17:30 Uhr: > On 03/08/2012 01:42 AM, Marc Schiffbauer wrote: > > * Ulrich Mueller schrieb am 08.03.12 um 08:27 Uhr: > >> Such constructs also cannot be used with any of the other proposed > >> solutions. And in fact, nobody is using such things in practice. > >> _All_ ebuilds in the Portage tree can be successfully parsed with the > >> regexp proposed. > > > > Ebuilds are bash scripts. I think introducing exceptions or > > constraints here is not straightforward. >=20 > Given that ebuilds already have to conform to a vast number of=20 > constraints that ordinary bash scripts do not. I think that it's=20 > perfectly reasonable for ebuilds to have a constrained syntax for EAPI=20 > assignments. There are constraints in ebuilds, right. But its an *ebuild* in the end, not an ordinary shell script. Thats true. So if EAPI is very special, and I am now convinced it is, then well,=20 this might be the most important contraint in an ebuild at all. If that is true I would vote to keep this as simple as possible: * EAPI *must* *be* the first non-Argument / shell code in an ebuild * The value of EAPI in the assignment *MUST* *NOT* contain any other variables or other shell substitutions. Period. Done. * That would be the least invasive change. * Could easily be checked by repoman * Is easy parsable by other programs (python code) -Marc --=20 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iD8DBQFPWelIKWxsyjWmQTQRArMSAJ9mIoaX63uOzevbU7/YEJ1MLfMy6wCeIwAc WFhOTg5XAvc7jxKg35T59zk= =jXrA -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--