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 1S6ucX-0007OZ-Lt for garchives@archives.gentoo.org; Mon, 12 Mar 2012 02:04:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B1F2EE0AE6; Mon, 12 Mar 2012 02:04:12 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 54CF6E0A95 for ; Mon, 12 Mar 2012 02:03:47 +0000 (UTC) Received: by iaoo28 with SMTP id o28so7310431iao.40 for ; Sun, 11 Mar 2012 19:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=T6wjBa3kxfHMwTUBs8q2y24UpgTuTVy8A69ip8GBy9E=; b=P9bKpWMQECF+OLT7Aw/TYGlxZFcygLkR1TWmmrjIyXk3JwTBl/PJDA++uvfFd19l+J HiCWxePfvNFgOnBNTt5jXcLzAaXiJXW7FLCbEqkcAWNT1cloOvtAmtioU5i+uqDvAzBK vEfJbu1koDHpcbplT6iS56GAhAn1Fu30N3aFb1Z3giz8g6oT/+k4O+Jiuo6ykJhcAlAR oFuHGs98lpS9Hd71YhkCuiELILdWtR2NmR1/bpI0v/ZxTiKYSFttI84OWxJqXsiuOKAJ u/67p5LR2hcnt2RzGxMrCo58hNAyIlPsGkWD+ESJ++nmDO1L3F/pVilttUDuKpHHBuXB BtIw== Received: by 10.50.154.170 with SMTP id vp10mr1899520igb.32.1331517826917; Sun, 11 Mar 2012 19:03:46 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id x1sm10827854igc.16.2012.03.11.19.03.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 19:03:46 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 11 Mar 2012 19:03:44 -0700 Date: Sun, 11 Mar 2012 19:03:44 -0700 From: Brian Harring To: Zac Medico Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds Message-ID: <20120312020344.GE7579@localhost> References: <4F58FC55.7070005@orlitzky.com> <20120308184820.108fc30c@googlemail.com> <4F592612.6050203@orlitzky.com> <20120309060424.09cdce1e@pomiocik.lan> <4F599692.9050503@orlitzky.com> <20120309172921.281ee5a0@pomiocik.lan> <4F5A368D.2020605@orlitzky.com> <20314.14772.897891.110368@a1i15.kph.uni-mainz.de> <4F5A3E6C.4040900@orlitzky.com> <4F5A4246.8080605@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5A4246.8080605@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 5ceb6cc3-f0dd-43a0-873d-2ef6f415c59b X-Archives-Hash: ca00f947199a3741dc5684ed7776537e On Fri, Mar 09, 2012 at 09:47:50AM -0800, Zac Medico wrote: > On 03/09/2012 09:31 AM, Michael Orlitzky wrote: > > On 03/09/12 12:11, Ulrich Mueller wrote: > >>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote: > >> > >>>> What if bash starts to parse the script completely and barfs at > >>>> 'syntax error' before it starts executing stuff? > >> > >>> It doesn't parse the script completely, it executes line-by-line, so > >>> we can bail out early. > >> > >> How can you tell that this behaviour won't be changed in a future bash > >> version? > >> > > > > Who's to say that in the future my computer won't be made out of > > delicious ice cream, eliminating the need for EAPIs entirely? > > > > Chances are, this would break thousands of scripts, so we hope they > > wouldn't do it. If it does happen, we either deal with it then, or don't > > upgrade to that version of bash -- the same as we would do with any > > other massive breaking change. > > Ulrich is talking about extensions which require a newer version of > bash. These kinds of extensions are quite common and don't cause > "massive breaking" because people simply have to upgrade bash in order > to use the new extensions, and their old scripts continue to run because > the new extensions don't interfere with backward compatibility. > > Your eapi() function proposal is especially fragile in this context > because it assumes that the installed version of bash will be able to > execute a script that may target a newer version of bash. This is a > special case that is typically not a problem, although it is a major > problem under the specific conditions that your eapi() function approach > induces. Pragmatic reality, the eapi function actually would work fine. As pointed out elsewhere, bash parses as it goes- which isn't going to change. If someone invokes 'eapi happy-meal' and it's not supported, the sourcing is stopped immediately, cache gets -happy-meal for the EAPI, and the pm continues to ignore the ebuild till either the ebuilds mtime changes (which case it redoes the metadata regen) or the PM now supports that EAPI, and... you guessed it, redoes the metadata regen. The cache behaviour is basically the same regardless of the EAPI mechanism. Now, this isn't to say everyone views the function as *optimal*. People can argue about that as much as they'd like. The point however is that it *would* work. Anyone claiming fragility/otherwise needs to put forth actual code examples. > Anyway, lets focus on our main goal, which is to decide on a way to > obtain the EAPI _without_ sourcing the ebuild. Nitpicking, but the point needs be made; this is *your* requirement. The requirement is to be able to deploy new globals/bash requirements/whatever. There is a difference. ~brian