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 1S7dF9-0002V4-FD for garchives@archives.gentoo.org; Wed, 14 Mar 2012 01:43:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33F9DE0AED; Wed, 14 Mar 2012 01:43:01 +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 7E1F4E0ABB for ; Wed, 14 Mar 2012 01:42:34 +0000 (UTC) Received: by iaoo28 with SMTP id o28so2014125iao.40 for ; Tue, 13 Mar 2012 18:42:34 -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=0YdnJWw8RPabHTICHdccse3jl+2iOj7656clq8ltjXc=; b=Qi1UIraVcmUgs1RQ5k/+yWPYpxm+kL3tn7AiibTL3PjKVHNlBbQHFGt5cCgQvijVr8 /Qh26qFduoGLFDaj5LcRwBPRfVYPQ3WyTTdVOTcoFydRYMY8/cZ5tF5+a0LPu10ZgKrj HCQkyf+LWn3wVt2b781uBqUjoj29TAVyinZpiPVFYvQu36FehqG9lxuSFBRAulXkvDsL rhexIM0o1sJlOxtfPTn8M0NyNiIfh5gaq7XnvnSBUHwTTE9L/+xD0Iycu6yTeZqJ9fYJ znkY08KhcbjQAnjtZfw9r8gzWQivjhROpBYd9l3Ox1TEPKL/U9KD9nxcuKi0WpNjQ5ru Qoag== Received: by 10.50.95.167 with SMTP id dl7mr8478714igb.6.1331689354050; Tue, 13 Mar 2012 18:42:34 -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 c2sm2182103igj.1.2012.03.13.18.42.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 18:42:32 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 13 Mar 2012 18:42:31 -0700 Date: Tue, 13 Mar 2012 18:42:31 -0700 From: Brian Harring To: Walter Dnes Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD : .ebuild is only bash Message-ID: <20120314014231.GA7731@localhost> References: <20120312155927.2cca0d3b@googlemail.com> <20318.11498.463319.52140@a1i15.kph.uni-mainz.de> <20120312171228.48c5b023@googlemail.com> <20120313064113.GA23544@waltdnes.org> <20120313073022.0781099c@googlemail.com> <20120314002903.GA2872@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: <20120314002903.GA2872@waltdnes.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: cd4d9a25-bca0-48f7-9bb6-16d4906a6d93 X-Archives-Hash: 0b2594fe9c4ffd2fe0287c9784c0306e On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote: > On Tue, Mar 13, 2012 at 07:30:22AM +0000, Ciaran McCreesh wrote > > > EAPI is special. You need to know EAPI to be able to get the rest of > > the metadata. > > > > > 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. > > > > That doesn't get you the EAPI. > > On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote > > > 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. > > I'm answering Ciaran's and Brian's posts together, because the answer > is the same for both... namely, we need a 2-pass processor, regardless > of whether it's bash/perl/python/whatever. Pass 1 checks for syntax > errors and retrieves "special" variables, answering Ciaran's concern. > Today, it's EAPI. In future, there may be others. Pass 2 does the > build, assuming no errors detected in pass 1. With respect, this statement carries no actual weight nor usefulness. PMs, by nature of dep resolution/building, already have that effective seperation. The point of this whole discussion is how to get metadata out of the ebuild w/out excessive burdens on future formats. This pass1/pass2 doesn't address that at all, nor actually relevant to the discussion at hand. Not trying to be a complete dick here, but you completely missed the points being discussed including actually responding to ciaran's point. I suggest you grab the sources of whichever PM you use, and audit how it gets metadata- it would help for understanding and contributing to this discussion. At the very least it would be useful having another person besides the Ulm/3 PM authors who actually are familiar w/ how this actually works at the core. > Under the heading of "syntax errors", I would include multiple EAPI > declarations. My response to Brian is that portage should not try to > outguess or fix or override an obviously broken ebuild. It should > return an error message (in this case "Multiple EAPI declarations not > allowed") and then halt. It is the ebuild-writer's job to come up with > a syntactically correct ebuild. And it's the PMs responsibility to enforce the rules of the environment; there in is part of the problem- portage is generally pretty lax about any form of strictness there, and has historically been that way. Even if one couldn't just point at portage, there still would be the problem of 3 different managers all needing to enforce the same tricky environment restrictions. Leaving it such that the PM has to enforce things like "don't have multiple EAPI assignments" means by default, one of them isn't going to... leading to the ebuilds breaking... specifically the common case being the ebuild becoming acclimated to some quirk of portage. EAPI was started to try and address that sensitivity (including rolling out new features), and the literal history of EAPI has involved dealing w/ quirks of portages past behaviour- including pre EAPI0. Generally speaking, the less ways something can be screwed up means less ways something *will* be screwed up. My point was that this can be pretty easily screwed up, and isn't as simple to enforce as people seem to think- that's not counting just flat out issues w/ the actual usage of it. ~brian