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 1S5iPu-0006BR-6B for garchives@archives.gentoo.org; Thu, 08 Mar 2012 18:50:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7015BE08C1; Thu, 8 Mar 2012 18:50:13 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 1374BE083B for ; Thu, 8 Mar 2012 18:49:27 +0000 (UTC) Received: by wico1 with SMTP id o1so603331wic.40 for ; Thu, 08 Mar 2012 10:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=V+nwckcN/FDc9CRFCx8+IZk4mWPPRyPFSKfKAvHrWoc=; b=UEETwUpTIB5dUakz7WN6xpquJH9SJ1WA+Xbl72oUej1a6BwZR0Sn7XPOHKlnDdfVMB 3IYwSg+IvbV0XHm/kwdod0xJ+G4dd97c1FVQoFiHqYOdq8+xuuJdEhJWeHOZLcMI87Lm 014L87BWXv4JIOQOTamX8LXcI3dEint2Gclwmq7fqZHIHNlO74ruQY8ufv6zNl6ISw5c +uD2fq/s90UKgBkCQu2uBCL1uOa75Adgm0aMsFrYMbL1Vk/kXHr6ei2dwqCMWvkttCkg H9uqmO1oPxJCLdgpR5KH7wi7SlHXP02vOyHR7lFUqObikGgoXK6tAPq8oZNsR40b1nsZ xjsg== Received: by 10.180.88.199 with SMTP id bi7mr15240764wib.12.1331232567301; Thu, 08 Mar 2012 10:49:27 -0800 (PST) Received: from localhost (cpc13-broo7-2-0-cust130.14-2.cable.virginmedia.com. [82.9.16.131]) by mx.google.com with ESMTPS id t20sm12499927wiv.0.2012.03.08.10.49.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 10:49:26 -0800 (PST) Date: Thu, 8 Mar 2012 18:48:20 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds Message-ID: <20120308184820.108fc30c@googlemail.com> In-Reply-To: <4F58FC55.7070005@orlitzky.com> References: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> <4F57DDB5.3090503@orlitzky.com> <20120308130310.69c3c714@pomiocik.lan> <4F58D6A5.7070804@orlitzky.com> <20120308182844.11201771@pomiocik.lan> <4F58F103.5010503@orlitzky.com> <20120308175345.2c4b72ff@googlemail.com> <4F58FC55.7070005@orlitzky.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; 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-SHA1; boundary="Sig_/HPL7KshFw9hU4YzfiuVsVDl"; protocol="application/pgp-signature" X-Archives-Salt: b90cc087-fde5-46d7-862e-2b9581ff6e7d X-Archives-Hash: 21b849e69d1d0acf59f11df2a172b7fb --Sig_/HPL7KshFw9hU4YzfiuVsVDl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 08 Mar 2012 13:37:09 -0500 Michael Orlitzky wrote: > > It probably should. Although in the early days the model for ebuilds > > was that they were scripts that were "executed", nowadays there's so > > much support required that it's better to think of ebuilds as being > > data. If you did have a /usr/bin/eapi5, it would have to be > > implemented as something that invoked the package manager, not as a > > direct interpreter. >=20 > Fair enough, but aren't you arguing the opposite point with Zac? If > ebuilds are data, fine, we write EAPI=3D4 somewhere and be done with > it. Anything not having that format is out-of-spec. The problem is that right now there's no way to determine the format of the data until you already know the format of the data. We hack around this by not allowing "drastic" format changes, where "drastic" includes "using things in newer versions of bash" and "not adding new global scope commands". The question under discussion is whether we a) keep "what format the data is in" as being part of the data, but impose some strange and arbitrary conditions on it, b) make a one-time change to have some kind of 'header' inside the file describing its format that isn't really part of the data itself, or c) admit that GLEP 55 already solved the problem and we might as well just fix the issue properly once and for all, even if GLEP 55's author is considered by some to be one of Satan's little minions. > If they're code, they're code, and we need to execute them somehow. The notion of "execute them somehow" that's used doesn't fit in with the #! interpreter model. You aren't executing ebuilds via an interpreter. You're performing an action that involves using the data and code in an ebuild multiple times and in multiple different ways, and that may also involve doing the same to an installed package that is being replaced. --=20 Ciaran McCreesh --Sig_/HPL7KshFw9hU4YzfiuVsVDl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9Y/vcACgkQ96zL6DUtXhHSOwCgism5OV+/So1kraYPDzS1iYuq gJAAoNQg8OewVCKOlsps2qRF6iZpb4NG =7mcc -----END PGP SIGNATURE----- --Sig_/HPL7KshFw9hU4YzfiuVsVDl--