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 1LbzUm-0003yL-Oo for garchives@archives.gentoo.org; Tue, 24 Feb 2009 15:46:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3C61E03E6; Tue, 24 Feb 2009 15:46:54 +0000 (UTC) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by pigeon.gentoo.org (Postfix) with ESMTP id 95F80E03E6 for ; Tue, 24 Feb 2009 15:46:54 +0000 (UTC) Received: from gw.thefreemanclan.net ([68.162.77.20]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFK005KYUHJT7Z1@vms173009.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Tue, 24 Feb 2009 09:46:36 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id E7D731759D85 for ; Tue, 24 Feb 2009 10:46:30 -0500 (EST) Message-id: <49A41656.7020100@gentoo.org> Date: Tue, 24 Feb 2009 10:46:30 -0500 From: Richard Freeman User-Agent: Thunderbird 2.0.0.19 (X11/20090104) 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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.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> <49A39CE7.4010201@gentoo.org> <49A3AAA1.6080207@gentoo.org> <49A3B947.2020907@gentoo.org> <49A3D0F6.6080307@gentoo.org> In-reply-to: <49A3D0F6.6080307@gentoo.org> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: d9290b25-e3e6-4c80-88b2-425432657ed6 X-Archives-Hash: cf53b1e6dc1bb46295a0f6a5f78b9d3a Alistair Bush wrote: > 4) Parsing the ebuild. But what are we parsing?, lets not limit > ourselves to bash, we might want to change languages completely. If it > is bash, what version, what if EAPI is set multiple times, what if its > set in an eclass. How do you do this if you're getting EAPI from the filename? How do you set it multiple times? How do you set it in an eclass if you're getting it from the filename? It seems like when we're talking about just putting the EAPI in a comment line on line x of the ebuild we're barraged with 47 ways that it will limit us, but when we're talking about EAPI in the filename suddenly we're not concerned with those limitations. If it helps maybe we need to split EAPI into two records - one that deals with how to fundamentally parse the file and find out the EAPI, and the other that implements everything else the EAPI does. I will certainly concede that putting it inside the ebuild potentially breaks compatibility with existing package managers. That is certainly a downside to this approach. However, none of the other objections that have been raised appear to hold water. An EAPI in a filename is a blob of text that needs to be parsed out in one particular way with one set of system calls. An EAPI embedded in the file is a blob of text that needs to be parsed out in one particular way with one set of system calls. And if backwards compatibility were a serious issue you could define a new ".ebuild2" file spec that incorporates the EAPI inside the file and current package managers would ignore it. Then you're not changing the file extension every time a new EAPI comes along, and the need to do so could be handled via future GLEPs. Or we could just delay implementation and clean up existing package managers and tell users to migrate.