1 |
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote: |
2 |
> >>>>> "CM" == Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> writes: |
3 |
> |
4 |
> CM> There's no need to offer the user the choice to do something that is |
5 |
> CM> always broken. Your car doesn't have a "connect the exhaust fumes to |
6 |
> CM> the air conditioning intake" button. |
7 |
> |
8 |
> Overriding portage's eclasses with one's own is not "always broken"; |
9 |
> your analogy is not at all on point. |
10 |
|
11 |
Overriding portage's eclasses with your own is already possible. You're |
12 |
asking to override portage's eclasses, without letting portage handle |
13 |
the fact that you are overriding eclasses. And that is a bad idea. You |
14 |
haven't commented, at least not in this thread that I have seen, on |
15 |
how to handle metadata changes as a result of eclass changes. |
16 |
|
17 |
Let's say this is in the tree: |
18 |
|
19 |
foo.eclass: |
20 |
DEPEND="dev-lang/python:2.6" |
21 |
|
22 |
bar-1.ebuild: |
23 |
inherit foo |
24 |
|
25 |
Let's say this is in your overlay: |
26 |
|
27 |
foo.eclass: |
28 |
DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )" |
29 |
|
30 |
Now you install bar. How should portage know that it must regenerate the |
31 |
metadata cache, to see that it doesn't need to install python 2.6 if you |
32 |
already have 3.1? |