From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C2D7C1381F4 for ; Tue, 14 Aug 2012 21:17:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 212AC21C0E3; Tue, 14 Aug 2012 21:15:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D1BE721C0C3 for ; Tue, 14 Aug 2012 21:09:19 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 137E91B4042 for ; Tue, 14 Aug 2012 21:09:19 +0000 (UTC) Message-ID: <502ABE7D.9050204@gentoo.org> Date: Tue, 14 Aug 2012 14:09:17 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120802 Thunderbird/14.0 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] RFC: [Future EAPI] Exporting phase funcs from direct inherits only References: <20120814114449.0db3d120@pomiocik.lan> <20120814214556.7b51551c@googlemail.com> <20120814225413.7aff9e02@pomiocik.lan> In-Reply-To: <20120814225413.7aff9e02@pomiocik.lan> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 476f0d1e-3f4c-4193-8427-c026350d5dff X-Archives-Hash: a662f6b965de1c8d99341bda98220f3f On 08/14/2012 01:54 PM, Michał Górny wrote: > On Tue, 14 Aug 2012 21:45:56 +0100 > Ciaran McCreesh wrote: > >> On Tue, 14 Aug 2012 11:44:49 +0200 >> Michał Górny wrote: >>> As some of you may have noticed, lately introduced 'double include >>> preventions' have caused changes in effective phase functions in a >>> few ebuilds. Also, often it is undesirable that change in inherits >>> of an eclass may cause an undesired change of exported functions. >> >> The problem here is that eclasses aren't clearly split between >> "utility" and "does stuff", so people are inheriting "does stuff" >> eclasses to get utilities. The fix is to stop having stupidly huge >> complicated eclasses; changing inherit behaviour is just wallpapering >> over the gaping hole. Ciaran's assessment sounds pretty accurate to me. > Soo, how do you propose to handle bug 422533 without changing inherit > behavior? Close it as WONTFIX. The ifndef thing that we're doing now seems like a reasonable approach. -- Thanks, Zac