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 1M5XfB-0003dz-EG for garchives@archives.gentoo.org; Sun, 17 May 2009 04:07:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 717B8E0538; Sun, 17 May 2009 04:07:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 32DA8E0538 for ; Sun, 17 May 2009 04:07:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id F09B364300 for ; Sun, 17 May 2009 04:07:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 required=5.5 tests=[AWL=2.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 phpbRPdRzyCY for ; Sun, 17 May 2009 04:07:37 +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 2C0F3642C5 for ; Sun, 17 May 2009 04:07:36 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M5Xeu-0004d9-QD for gentoo-dev@gentoo.org; Sun, 17 May 2009 04:07:32 +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 ; Sun, 17 May 2009 04:07:32 +0000 Received: from couldbe by 87-194-16-43.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 May 2009 04:07:32 +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: Sun, 17 May 2009 04:07:18 +0000 (UTC) Message-ID: References: <200905142006.51998.patrick@gentoo.org> <20090516230603.1a689107@snowmobile> 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: 163cd4fb-1f3c-46d0-9fab-81197e7b499f X-Archives-Hash: 94cff2268e3c518cfe9ea8c01e932875 Ciaran McCreesh googlemail.com> writes: > > On Sat, 16 May 2009 21:58:10 +0000 (UTC) > Mark Bateman soon.com> wrote: > > "The current way of specifying the EAPI in ebuilds is flawed" > > That is not defining the problem, that is an opening statement. > > That is the problem. No, that is a summary of the problem. Not once has the actual problem been described or documented. It has been requested multiple times by multiple people and yet a description detailing the problem has yet to materialise. Repeated use of *problem* doesn't suddenly expand on the definition of the word *problem* to encompass details needed in a technical proposal within a GLEP. If you do not understand the problems associated with determining the EAPI of an ebuild before sourcing it, please stop championing this GLEP until someone does provide a complete breakdown of the process. Until such information is provided continued discussion of this GLEP is not going to progress since words like *obviously* are substituted for actual facts, a substitution which does not provide anything new to this discussion > > "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 > > Yes, it is the only method. No it is the only method you are willing to accept, there is a big difference. Many people have mentioned in passing other means of determining the EAPI of an ebuild pre-sourcing (thus allowing the PM to source the correct eclass or flag up warnings...) YET they have just been shot down with no actual technical reason, except "they do not involve coding the EAPI into the filename". Please provide detailed technical description of the problem, as has been requested by a number of people, as well as providing details of why in-filename encoding of EAPI is technically as well as practically the best solution. > > > Where is it defined that the ebuild must be sourced 1st? > > Why does the ebuild have to be sourced 1st? > > Such things are obviously true to anyone with a basic understanding of > the domain. So you are unable to actually reference any credible source of information to back up your claims then. > > > 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 > > Except that that isn't true. With the current rules, an ebuild has to > be sourced to get EAPI. And you can't just say "use the metadata > cache", since the package manager has to know how to generate the > metadata cache in the first place. > > Please make sure you're familiar with the basics of how metadata works > before commenting any further. > What has my understanding or lack of understanding of "metadata" have to do with my statement that other means exist to determine the EAPI of an ebuild before sourcing said ebuild? This is meant to be a discussion about "The fallacies of GLEP55" Refusal to accept any other possible solution as well as refusal to discuss any other solution to the problem, all wrapped up in an awe of supremacy on the matter (without ONCE providing details) is not beneficial to Gentoo in finding the best solution. Simple fact is there are many methods available to determine the EAPI of an ebuild without having to encode it in the filename (or its extension). In fact you yourself have mentioned that eclasses change the EAPI http://article.gmane.org/gmane.linux.gentoo.devel/61255 "But eclasses have tried changing it. This is something people have done, not some hypothetical." So the need to have it actually encoded in the filename is not needed, since other method's of actually setting the EAPI exist and work. Blindly dismissing a solution without actually providing any technical information of the problem AS well as why a *proposed* solution isn't the best is of no benefit to solving the problem For instance SheBangs are very useful FILE:test1.py #!/usr/bin/python2.5 #-*- coding: utf-8 -*- def bin(number,count): return '0b'+"".join([str((number >> y) & 1) for y in range(count-1,-1,-1)]) print 'hello world ',bin(170,8) FILE:test2.py #!/usr/bin/python2.6 #-*- coding: utf-8 -*- print('hello world',bin(170)) executing ./test1 and ./test2 both work WHILE "python2.5 test2.py" fails on NameError. There is no need for the python version to be encoded into the filename (like *.py-2.6) and yet it still works.