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 1M5RuD-0001Qr-HR for garchives@archives.gentoo.org; Sat, 16 May 2009 21:58:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 81322E0497; Sat, 16 May 2009 21:58:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3C025E0497 for ; Sat, 16 May 2009 21:58:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E96F264203 for ; Sat, 16 May 2009 21:58:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 required=5.5 tests=[AWL=2.308, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fkAusbUOnFY for ; Sat, 16 May 2009 21:58:46 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 3562865816 for ; Sat, 16 May 2009 21:58:44 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M5Rtm-0000Id-QQ for gentoo-dev@gentoo.org; Sat, 16 May 2009 21:58:30 +0000 Received: from 87-194-16-43.bethere.co.uk ([87.194.16.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2009 21:58:30 +0000 Received: from couldbe by 87-194-16-43.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 May 2009 21:58:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Mark Bateman Subject: [gentoo-dev] Re: The fallacies of GLEP55 Date: Sat, 16 May 2009 21:58:10 +0000 (UTC) Message-ID: References: <200905142006.51998.patrick@gentoo.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-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 87.194.16.43 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.65 Safari/525.19) Sender: news X-Archives-Salt: 3f6cbfa3-66c4-49b1-8917-e579c9443586 X-Archives-Hash: 8a21bec544a457c405fa146d7230f889 Patrick Lauer gentoo.org> writes: > > For quite some time (over a year, actually) we've been discussing the > mysterious and often misunderstood GLEP55. > [http://www.gentoo.org/proj/en/glep/glep-0055.html] > > The proposed solution to a problem that is never refined, in short, is to add > the EAPI into the ebuild filename "to make things easier". Which is a rather > unsubstantiated idea that doesn't really add up if you look at it ... and it > adds some artifacts that we've been laughing about for a decade because > microsoft did the exact same thing (binding the executable-ness of a file to > the filename). > The problem isn't GLEP55 (as such), it is a bit more subtle then that and runs deeper then just this GLEP. For starters it is the whole GLEP process GLEP [Gentoo Linux Enhancement Proposals] is meant as a central place to pull *proposals* that provide enhancements to Gentoo. Some are quite self-apparent (GLEP08) others are a bit more... lacking (GLEP55) Why is GLEP55 lacking? because it providing a "solution" to a problem that is not actually defined "The current way of specifying the EAPI in ebuilds is flawed" That is not defining the problem, that is an opening statement. "In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place." It then describes "a" mechanism utilising an ebuild (source /usr/portage...) to obtain the EAPI from within the ebuild (EAPI=...). Using this method the entire content of GLEP55 is accurate. However, this is not the only method to determine the EAPI of an ebuild that exists and as such the viability of GLEP55 as the best solution is brought into question Where is it defined that the ebuild must be sourced 1st? Why does the ebuild have to be sourced 1st? This then results in ml participants taking this GLEP as the *only* solution (to a problem that hasn't actually been defined...) with statements like "That's *obviously* completely wrong" If something was so obvious this GLEP would have been approved/rejected by now, but it hasn't because the problem isn't defined "because it is obvious" If a problem cannot be describe then the problem is not understood by the one writing about the problem. The GLEP process needs to be refined such that some means of initially raising a problem (be it a GLEP itself) that describes the problem in as much detail as possible. Once said GLEP has been accepted, ie the problem is acknowledged, (sub) GLEP's can be submitted providing possible solutions to the problem. This way the problems encounted with this particular GLEP, a GLEP that keeps on re-surfacing, would be minimised GLEP55 explicitly states that the EAPI to be recorded in the file extension, while, as this thread has shown, a number of methods can be used to source the EAPI version of the ebuild *without* the need of actually source'ing the ebuild (grep, sed, metacache) all of which are viable solutions to the problem, the problem that is so obvious it doesn't actually have to be defined Thing is the package manager *needs* to know the EAPI that the ebuild complies to before it can source it to ensure 1) the correct EAPI-specific eclass is inherited 2) Package manager needs to protect itself from ebuild syntax that earlier system packages (eg bash) would fail with So please just reject GLEP55, not because its wrong but because it is incomplete reject GLEP55 and have a GLEP62 submitted which defines the problem, then request GLEP62-{1,2,3...} be submitted providing possible solutions to the problem. GLEP55 can then be submitted as a possible solution. Then developers/council can vote on the sub-GLEP's to choose which solution is the best technically as well as what is best for the users (dev's and general users) Traceability of issues and solutions is needed, traceability that extends beyond mailing-lists and irc logs (discussion mediums which are good for instantaneous discussion of issues, but are rubbish for returning to an issue a few years down the line, no matter how many logs exist). Report the problem better How clear is it from the stored infomation available whether EAPI's when they were 1st conceived and added to portage/paludis/pkgcore was the best solution to the problem of expanding on ebuild capability. Or more to the point was how it was done partly responsible for the mess we are in now? If the problem on ebuild expansion was better documented and defined, maybe this GLEP wouldn't even exist, we may have been already using *.ebuild-3 because it was the best solution