From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LbdJy-0007nl-Tq for garchives@archives.gentoo.org; Mon, 23 Feb 2009 16:06:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11628E04CC; Mon, 23 Feb 2009 16:06:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E4D98E04CC for ; Mon, 23 Feb 2009 16:06:01 +0000 (UTC) Received: from localhost (0x3ef266d2.svgnxx4.dynamic.dsl.tele.dk [62.242.102.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 99BB4B5ACE for ; Mon, 23 Feb 2009 16:06:00 +0000 (UTC) Date: Mon, 23 Feb 2009 17:06:17 +0100 From: Peter Alfredsen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090223170617.27ae85ae@gentoo.org> In-Reply-To: <49A2C40D.3060601@gentoo.org> References: <1234257125.18160.2016.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> <49A2B276.1000109@gentoo.org> <49A2C40D.3060601@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit X-Archives-Salt: 7a2c65d5-b36c-4755-82bb-e610c03027fc X-Archives-Hash: 579148018865a680d0724b8ae71db2c4 On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb wrote: > Plus, I don't really grasp the whole "we have to source the whole > ebuild to know the EAPI version" argument. It's one variable, in one > line. Can't a simple parser get that and go from there? The problem is that its technically allowed for the value of $EAPI to be dependent on other bits and pieces. For instance: if [[ $PV = 2.6 ]] then EAPI=2 else EAPI=1 fi The quick-n-dirty solution to that is to just say that EAPI is not just a bash variable, it's also a magic string, so manipulating it in bash is forbidden. And please place it in line 5 of your ebuild, kthxbye. To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. /loki_val