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 1S6wMl-0004um-Cw for garchives@archives.gentoo.org; Mon, 12 Mar 2012 03:56:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A0D0E094B; Mon, 12 Mar 2012 03:56:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id F09F5E08F8 for ; Mon, 12 Mar 2012 03:55:23 +0000 (UTC) Received: from [192.168.26.2] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 62B651B4053 for ; Mon, 12 Mar 2012 03:55:23 +0000 (UTC) Message-ID: <4F5D73A8.2080104@gentoo.org> Date: Sun, 11 Mar 2012 20:55:20 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120304 Thunderbird/10.0.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds 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> <20120312020344.GE7579@localhost> In-Reply-To: <20120312020344.GE7579@localhost> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: f0449e12-1600-40e8-804d-c3343e01d05f X-Archives-Hash: 17935789692ad399677b76438d83bed9 On 03/11/2012 07:03 PM, Brian Harring wrote: > 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. Suppose that EAPI 5 requires bash-5. There may be bash-5 syntax in the ebuild prior to your eapi() function call, causing a fatal syntax error. >> 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. Well, I think most people would tend to accept my requirement, and that it falls within the realm of common-sense if avoiding unnecessary complexity is one of our goals. -- Thanks, Zac