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 <gentoo-dev+bounces-40814-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1O3yno-0005np-OM
	for garchives@archives.gentoo.org; Mon, 19 Apr 2010 21:46:48 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 7AABEE0955;
	Mon, 19 Apr 2010 21:46:44 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id 00B83E0538
	for <gentoo-dev@lists.gentoo.org>; Mon, 19 Apr 2010 21:46:33 +0000 (UTC)
Received: from gentoo.org (5ED618E1.cable.ziggo.nl [94.214.24.225])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.gentoo.org (Postfix) with ESMTP id 661A21B404D
	for <gentoo-dev@lists.gentoo.org>; Mon, 19 Apr 2010 21:46:31 +0000 (UTC)
Date: Mon, 19 Apr 2010 23:46:17 +0200
From: Harald van =?utf-8?Q?D=C4=B3k?= <truedfx@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
Message-ID: <20100419214617.GA23143@boostbox>
References: <4BB536DC.8090405@gentoo.org>
 <m36344slr9.fsf@lugabout.jhcloos.org>
 <4BBB7FDE.7090306@gentoo.org>
 <m3sk70lhdb.fsf@lugabout.jhcloos.org>
 <4BC3A301.3040400@gentoo.org>
 <m3ljcn16z7.fsf@lugabout.jhcloos.org>
 <20100416212806.7bc6b307@snowmobile>
 <m3vdbpzbfa.fsf@lugabout.jhcloos.org>
 <20100418084502.49030e16@snowmobile>
 <m3zl0zw43i.fsf@lugabout.jhcloos.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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-Disposition: inline
In-Reply-To: <m3zl0zw43i.fsf@lugabout.jhcloos.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Archives-Salt: 8e54502f-f018-4ad0-9767-d0a9174cb1df
X-Archives-Hash: 955844e311be5692927039af1e12b2e1

On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> 
> CM> There's no need to offer the user the choice to do something that is
> CM> always broken. Your car doesn't have a "connect the exhaust fumes to
> CM> the air conditioning intake" button.
> 
> Overriding portage's eclasses with one's own is not "always broken";
> your analogy is not at all on point.

Overriding portage's eclasses with your own is already possible. You're
asking to override portage's eclasses, without letting portage handle
the fact that you are overriding eclasses. And that is a bad idea. You
haven't commented, at least not in this thread that I have seen, on
how to handle metadata changes as a result of eclass changes.

Let's say this is in the tree:

foo.eclass:
DEPEND="dev-lang/python:2.6"

bar-1.ebuild:
inherit foo

Let's say this is in your overlay:

foo.eclass:
DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )"

Now you install bar. How should portage know that it must regenerate the
metadata cache, to see that it doesn't need to install python 2.6 if you
already have 3.1?