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 1LhoYA-0008MT-6Q for garchives@archives.gentoo.org; Thu, 12 Mar 2009 17:18:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69D4CE01CB; Thu, 12 Mar 2009 17:18:28 +0000 (UTC) Received: from mailfilter6.ihug.co.nz (mailfilter6.ihug.co.nz [203.109.136.6]) by pigeon.gentoo.org (Postfix) with ESMTP id 4B010E01CB for ; Thu, 12 Mar 2009 17:18:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQBAL+LX0l2XJP3/2dsb2JhbAAIyXKFcoFp X-IronPort-AV: E=Sophos;i="4.38,351,1233486000"; d="scan'208";a="82508871" Received: from 118-92-147-247.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([118.92.147.247]) by smtp.mailfilter6.ihug.co.nz with ESMTP; 13 Mar 2009 06:18:25 +1300 Message-ID: <49B943D0.9040306@gentoo.org> Date: Fri, 13 Mar 2009 06:18:08 +1300 From: Alistair Bush User-Agent: Thunderbird 2.0.0.19 (X11/20090228) 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] Collecting opinions about GLEP 55 and alternatives References: <49A472E3.1010204@gentoo.org> <1236675215.12714.48.camel@sapc154.salomon.at> In-Reply-To: <1236675215.12714.48.camel@sapc154.salomon.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: a150e7f8-8f77-4ee7-a225-619ca9791895 X-Archives-Hash: 7e518a25270a4ab13c1ec87a6348399c Michael Haubenwallner wrote: > Hi, > > Reminder (for myself): > As long as we want/have to support PMs lacking EAPI detection in > '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI > to an '*.ebuild' must be hackish. So we can try to find the least ugly > hack, or we need to change the extension. > > So just another idea, based on the "eapi() function" one: > As inherit() is the only(?) global function provided by old PMs, the > first non-commentary/non-blank line in '*.ebuild' could read: > > inherit eapi > > Compliant PMs identify 'eapi' as a special eclass name (with or without > sourcing the ebuild), to know that "this ebuild specifies an EAPI". > > For non-compliant PMs, we need to provide an 'eapi.eclass', which just > spits some 'your PM lacks EAPI support' message and causes the PM to > mask this ebuild 'by corruption' or the like. > > Or - what are old PM's messages when an eclass is missing? > > Eventually, this line also could finally specify the EAPI and read: > > inherit eapi 4 > > Because non-compliant PM's already quit because of (missing or dying) > eapi.eclass, there is no need to have a '4.eclass'. How would the 4.eclass determine whether the package manager actually supports the eapi? inherit is a function remember so any "special" parsing will not change the fact the the inherit function will be called. Will then need to determine whether there is actually a PM that doesn't support the eclasses EAPI and then die. What are the implications of calling inherit multiple times within an ebuild? Im sorry, but this just sounds like a HACK, and a hacky hack at that. > > /haubi/