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 1MAtSu-00086q-4d for garchives@archives.gentoo.org; Sun, 31 May 2009 22:25:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B571AE03A3; Sun, 31 May 2009 22:25:14 +0000 (UTC) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by pigeon.gentoo.org (Postfix) with ESMTP id 9B67EE03A3 for ; Sun, 31 May 2009 22:25:14 +0000 (UTC) Received: from gw.thefreemanclan.net ([71.242.220.77]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KKJ0045M47B88D0@vms173019.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Sun, 31 May 2009 17:09:16 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 25C941759CCD for ; Sun, 31 May 2009 18:09:11 -0400 (EDT) Message-id: <4A230007.9090708@gentoo.org> Date: Sun, 31 May 2009 18:09:11 -0400 From: Richard Freeman User-Agent: Thunderbird 2.0.0.21 (X11/20090321) 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] A new glep: Ebuild format and metadata handling References: <200905311556.19190.patrick@gentoo.org> In-reply-to: <200905311556.19190.patrick@gentoo.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: ec12c281-c031-4e24-a94d-b6cbc6a745a9 X-Archives-Hash: 810129962cebe91abc46944eaff05aa4 Patrick Lauer wrote: > If I should have forgotten any approach or misrepresented one I'd > appreciate an updated or rephrased section so it can be easily > updated. > This keeps coming up for some reason: parsers: It enforces some minor limitations, for example EAPI needs to be unique and cannot be overridden by eclasses. I agree with this sentence. However, the exact same limitation applies to GLEP55 and it isn't mentioned there. So, that paragraph should read: glep55: See GLEP55. To summarize: The eapi is put into the file name so that the package manager knows the EAPI (and thus how to handle this file format). While it simplifies the eapi discovery this comes at a high price as there is no reliable way to find and validate all ebuilds. It also enforces some minor limitations, for example EAPI needs to be unique and cannot be overridden by eclasses. Some people also see it as bad design as it exposes file internals in the filename. Likwise, the pro/con list for glep55 should include the line: (+-) enforces some restriction on the possible changes in future EAPIs In this particular regard the parser and the glep55 approach have the exact same limitations. Now, an alternative to glep55 that has two different EAPI-like values (one for the initial file parsing and one for actually performing the build) might lose this limitation. However, this is not the case with glep55 as it is presently stated.