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 1LglZB-0005Q0-4f for garchives@archives.gentoo.org; Mon, 09 Mar 2009 19:55:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3FFA4E051B; Mon, 9 Mar 2009 19:55:11 +0000 (UTC) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by pigeon.gentoo.org (Postfix) with ESMTP id 22457E051B for ; Mon, 9 Mar 2009 19:55:11 +0000 (UTC) Received: from gw.thefreemanclan.net ([68.162.78.19]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KG90003Y8NF48GJ@vms173003.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Mon, 09 Mar 2009 14:54:56 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 8D08A1759EA6 for ; Mon, 09 Mar 2009 15:54:50 -0400 (EDT) Message-id: <49B57409.5050406@gentoo.org> Date: Mon, 09 Mar 2009 15:54:49 -0400 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] Re: Collecting opinions about GLEP 55 and alternatives References: <49A472E3.1010204@gentoo.org> <4afbebfe0903090601r5759177bt98639c0c3a61b894@mail.gmail.com> In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 42f7f7a1-3a48-427d-9700-3a06e58bf4fd X-Archives-Hash: 977a8a493451b1ae4e5f5913e8457202 Duncan wrote: > So putting it in the manifest but generated from the ebuild info really > doesn't change the problem, leaving us precisely where we were before, > except that it may be useful as a component of one of the other > solutions, and has been proposed as such in a few of the suggested > variants. > I think that it does address ONE aspect of the limitations of putting EAPI in the build - but not all. One issue with EAPI in the build is figuring out what it is without sourcing the ebuild (possibly using a package manager that doesn't realize that it doesn't know how to source it). If the developer of an ebuild prepares the manifest, then at least their package manager will know how to handle the ebuild and extract the EAPI. Now, that could still be messy if it needs to source the ebuild 3 ways before finding the one that delivers the correct EAPI. However, end-user package managers wouldn't need to source the ebuild to figure out the EAPI. Potentially the developer could just manually put the EAPI in the manifest (or use a tool to do this). Obviously this is an extra step when adding ebuilds to the tree, but that would completely address the issues with sourcing builds. Changing the manifest format of course creates backwards compatibility issues. So, I wouldn't dismiss this idea out of hand - it isn't completely equivalent to the other options.