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 1M537B-0004gx-Pt for garchives@archives.gentoo.org; Fri, 15 May 2009 19:30:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DBC5DE0330; Fri, 15 May 2009 19:30:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 95BA3E0330 for ; Fri, 15 May 2009 19:30:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 38DFE6610C for ; Fri, 15 May 2009 19:30:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 required=5.5 tests=[AWL=0.662, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 K8PAwdSbZWkD for ; Fri, 15 May 2009 19:30:34 +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 3758A65685 for ; Fri, 15 May 2009 19:30:33 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M536z-0008DJ-UN for gentoo-dev@gentoo.org; Fri, 15 May 2009 19:30:29 +0000 Received: from 82.152.214.146 ([82.152.214.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 May 2009 19:30:29 +0000 Received: from slong by 82.152.214.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 May 2009 19:30:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: The fallacies of GLEP55 Date: Fri, 15 May 2009 20:29:16 +0100 Organization: Friendly-Coders Message-ID: <1461811.mMo8WK9hvy@news.friendly-coders.info> References: <200905142006.51998.patrick@gentoo.org> <20090514193907.56754ae6@snowcone> <200905142105.53027.patrick@gentoo.org> <4A0C6DFB.3060208@robbieab.com> 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: 82.152.214.146 Sender: news X-Archives-Salt: b8891db3-49dd-4e61-98d5-dc236896bb67 X-Archives-Hash: 9bc97f95b2316a039c14b20300da44fa Robert Bridge wrote: > Patrick Lauer wrote: >> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: >>> On Thu, 14 May 2009 20:06:51 +0200 >>> >>> Patrick Lauer wrote: >>>> Let EAPI be defined as (the part behind the = of) the first line of >>>> the ebuild starting with EAPI= >>> Uh, so horribly utterly and obviously wrong. >>> >>> inherit foo >>> EAPI=4 >>> >>> where foo is both a global and a non-global eclass that sets metadata. >> >> Interesting, but quite subtly wrong. I'm surprised that you try to slip >> such an obvious logical mistake in in an attempt to save your arguments. > > Patrick, in the interest of making this comprehensible to the average > schmuck like me, which you seem to be trying to do, could you actually > explain WHY this is wrong? Otherwise it looks like you are simply trying > the arrogant "I am right because I say so" line. > AFAIK, setting EAPI has to be done before any call to inherit. Not to do so is considered a QA violation, and I believe repoman will scream at you if you do so (I could be wrong as I don't use it. If it doesn't, perhaps it should.) Furthermore, eclasses are not supposed to set EAPI. They can test what the ebuild's EAPI is, and act accordingly, should the need arise, but they are not supposed to set it. (I'm informed this is disallowed by GLEP-55 in any event, so it's not a restriction anyone cares too much about, one would surmise.) >From conversation with Harring, who invented the whole EAPI thing, they were never meant to change very quickly. The complementary mechanism was elibs, that is files with useful library functions, which is often how eclasses are used nowadays. Eclasses in that context would be able to set EAPI, since they would effectively be a template, not a repository of functionality. (This is my no doubt flawed understanding of what he said; I'm sure he'll correct, and hopefully forgive, any errors which are of course my own.) I am curious as to why eclass versioning, which has been proposed for donkey's years, hasn't seen as much impetus as what appear from a software engineering perspective to be quite esoteric, and poorly thought-through, use-cases. There does appear to be a process issue, though resolution is another matter. Good luck with the distro. :-) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)