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 1S6uUf-0006NF-Qf for garchives@archives.gentoo.org; Mon, 12 Mar 2012 01:56:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7259CE0AB5; Mon, 12 Mar 2012 01:56:04 +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 678E6E0A68 for ; Mon, 12 Mar 2012 01:55:36 +0000 (UTC) Received: by iaoo28 with SMTP id o28so7300654iao.40 for ; Sun, 11 Mar 2012 18:55:36 -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=nrPm4+dtmYs9lYhnaVJEpuRppR59HqlndlXEfB40nF0=; b=lERkZiB/5xOtEBmYPwQPgJY3U6lQSbAx9IZjQwJqViIQYkiSOXJZuBc+TjaUJdWTvX W3TGGbr0xAZxTFDCf2YmqQoMuXMN3iX/aRl6l9OU5C6OVrvP5zoxk+BhJgs59ku8ExyO 4wfYknwHwqPmIpRcTyMAKxYZSLKgRpmYMYFlLA4VKBKksMNcH7s1uhoP4PKAxOiTleSc X129fJqchLnEUPsO/Qf3IoRtLe+vA/2an/izCdhS7U8N4AMDXuWk/afpLGXTwe27vHNu q8rsN0AhjKtCRSvVi7iwEYUeMMxkK/fTsdQfY5vGPY3OPbiEvtbYkY7PCjGbkWFVsOxo ECQA== Received: by 10.50.178.38 with SMTP id cv6mr16234420igc.1.1331517335954; Sun, 11 Mar 2012 18:55:35 -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 df2sm8016987igb.10.2012.03.11.18.55.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 18:55:35 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 11 Mar 2012 18:55:33 -0700 Date: Sun, 11 Mar 2012 18:55:33 -0700 From: Brian Harring To: zmedico@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds Message-ID: <20120312015533.GD7579@localhost> References: <4F599A61.8010600@gentoo.org> <4F5A16C5.7050303@orlitzky.com> <4F5A1C46.7080005@gentoo.org> <4F5A2001.30309@orlitzky.com> <4F5A2495.4060305@gentoo.org> <20120309125126.186969f9@gentoo.org> <4F5A28B6.2010404@gentoo.org> <4F5A34A8.4080200@orlitzky.com> <20120309192054.776bcd56@googlemail.com> <4F5B7C1A.6060509@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: <4F5B7C1A.6060509@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 409ff24a-a39d-47cb-ad32-3cf8e8ec62df X-Archives-Hash: 45159a1ddc0159cf7c2bd1c7444d70cf On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote: > On 03/09/2012 11:20 AM, Ciaran McCreesh wrote: > > On Fri, 09 Mar 2012 11:49:44 -0500 > > Michael Orlitzky wrote: > >>>> isnt the whole point of the proposal to get eapi without sourcing ? > >>>> > >>>> so that we can use new bash features at local or global scope > >>>> without risking that people with an old bash get syntax errors > >>>> trying to get the eapi > >>> > >>> Right. Michael has lost sight of the goal and is moving off on a > >>> tangent. > >> > >> The point was to be able to get the EAPI without crashing if the > >> ebuild uses newer features. > > > > No, it's not. There's more to it than that. > > > > Some EAPIs really require defining certain environment variables, shell > > options, sandbox things etc *before* the sourcing starts. It's a massive > > pain in the ass to try to handle setting that kind of thing on the fly > > once the sourcing has already started. Knowing the EAPI before having > > to spawn a bash process isn't just about performance, it's also about > > making ebuilds much less difficult to deal with. > > Yeah. Another way of putting it is that the requirement to spawn a bash > process and source the ebuild adds a ridiculous amount of unnecessary > complexity, in violation of the KISS principle [1]. This statement is incorrect. Even if EAPI could be parsed via some non sourcing approach, we *still* have to source the ebuild to get the metadata for when the EAPI is supported (the vast majority of usage). That complexity is there one way or another- we wouldn't be trying to extract the EAPI from the ebuild unless the cache was invalid/missing. Phrasing it more bluntly: you can only avoid the sourcing step if you can isolate that the EAPI is unsupported (which is extremely rare in terms of actual user experience). For the rest of the time (well past the 99% mark) sourcing is the immediate step following. Also, stop referencing wikipedia. People know what "trivial objection" and "KISS" is. Pointing at random wikipedia links when people object is just a form of fallacious argument from authority ( http://en.wikipedia.org/wiki/Argument_from_authority ). :P ~brian