On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote: > >>>>> "CM" == Ciaran McCreesh <ciaran.mccre...@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?
