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 1S7LnC-0002O0-RG for garchives@archives.gentoo.org; Tue, 13 Mar 2012 07:05:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3C89E0BC9; Tue, 13 Mar 2012 07:04:47 +0000 (UTC) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 2DB3CE0E4E for ; Tue, 13 Mar 2012 07:03:37 +0000 (UTC) Received: by ggni4 with SMTP id i4so265101ggn.40 for ; Tue, 13 Mar 2012 00:03:37 -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=mfHt3+ZCQkZniJWVTcNkt0akOau3WGVAV7x29nTfoKg=; b=cB7ENv6U7TM4JsAhy4iiQeZIjT5RB5ZtVphg6tTM+KVSTT76nYDgdYfRHlX8SfGZ0y BCi4t8LDdV9aSezjT8cJ1rQh9P9IHe6OXjFfHsWFVXz0FknrCAj7TvPzJ8OTvECUJ+JS KXhhvlBUb2NT4NagxnrBxe0FWzoQhqAl9SinCJwsWHyZnLaEXIdmEwfNVRw9LYyMYNpv rft5oc3BIvMxBg69KF7p0C5COtiKE+Dt02xCFnPPxprYBUZ6+Ts5dkmK9txLHBXkG9eU 1IDXLKE3fc2X4NPOm//eHYKS4GdjLhn3qMITL1xjC41blIifeppHm2WNkqUHcOPECYft Wcgg== Received: by 10.182.14.34 with SMTP id m2mr10725957obc.38.1331622217579; Tue, 13 Mar 2012 00:03:37 -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 a6sm14213580oea.13.2012.03.13.00.03.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 00:03:36 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 13 Mar 2012 00:03:34 -0700 Date: Tue, 13 Mar 2012 00:03:34 -0700 From: Brian Harring To: Walter Dnes Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD : .ebuild is only bash Message-ID: <20120313070334.GK7579@localhost> References: <20120312155927.2cca0d3b@googlemail.com> <20318.11498.463319.52140@a1i15.kph.uni-mainz.de> <20120312171228.48c5b023@googlemail.com> <20120313064113.GA23544@waltdnes.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: <20120313064113.GA23544@waltdnes.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: ed005bd8-7558-4fcb-9656-01b5b0b24353 X-Archives-Hash: e0acb2ba65f54ed981d70da76736d701 On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: > On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote > > > This whole thing is just an exercise in trying to find excuses not to > > use GLEP 55. > > A filename should not be (ab)used as a database. The main argument for > GLEP 55 is that it would make ebuild-processing generic. I.e. making > ebuild info available to whatever future ebuild processor replacement > for bash was used. A couple of comments... > > 1) Let's talk generic. Right now, we're talking about EAPI. In future, > what other (meta)data and characteristics will we need to know? What > else will be tacked onto the filename? EAPI, and any other critical > (meta)data should be declared early on in the ebuild. That's what the > ebuild is for. > > 2) Any potential ebuild processor that's incapable of looking for regex > "^EAPI=" in a textfile, amd parsing the numbers that follow, has no > business being used to process ebuilds. Perfectly valid, if stupid, bash: EAPI=3 EAPI=4 Which is the PM to choose? Because if your answer is "the first", then you need to keep in mind that any following code (including eclasses that test eapi) will be seeing the second during sourcing. Nice little gotcha, that one. I'm aware people have suggested "make EAPI readonly" to try and deal w/ this; that however means it'll break any PM that uses eval for loading the ebuild, and means that every ebuild sourcing for phase running will throw a complaint about EAPI being readonly. I don't hugely expect PMs to screw up the ordering of which to chose, although it exists; trying to ban secondary settings is also an approach... but all of it points to the fact it's a fricking hack and isn't really worth doing. If we're going to redo EAPI, redo it right. Don't half ass it- this time around we're not forced to make compromises. Viewing it that way, this grep hack shouldn't be on the table as a viable option. ~harring