1 |
>>>>> "HvD" == Harald van Dijk <truedfx@g.o> writes: |
2 |
|
3 |
HvD> Let's say this is in the tree: |
4 |
|
5 |
HvD> foo.eclass: |
6 |
HvD> DEPEND="dev-lang/python:2.6" |
7 |
|
8 |
HvD> bar-1.ebuild: |
9 |
HvD> inherit foo |
10 |
|
11 |
HvD> Let's say this is in your overlay: |
12 |
|
13 |
HvD> foo.eclass: |
14 |
HvD> DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )" |
15 |
|
16 |
HvD> Now you install bar. How should portage know that it must regenerate the |
17 |
HvD> metadata cache, to see that it doesn't need to install python 2.6 if you |
18 |
HvD> already have 3.1? |
19 |
|
20 |
It shouldn't bother. :) |
21 |
|
22 |
Really, that isn't the kind of change that I find I need to make. |
23 |
|
24 |
And it should never regenerate the metadata cache (ie portage/metadata/cache). |
25 |
The docs used to -- and probably still do -- recommend regenerating that |
26 |
cache after certain changes. Which is a drasticly bogus suggestion unless |
27 |
you have a *very* fast system. Even across a dialup straw, an emerge --sync |
28 |
is orders of magnitude faster. |
29 |
|
30 |
If the ebuild calls a class which has been overridden by a local class, and |
31 |
the original class set DEPENDs or the like, then as it reads in the new class |
32 |
file it should just use those values in place of the ones in the cache. |
33 |
|
34 |
-JimC |
35 |
-- |
36 |
James Cloos <cloos@×××××××.com> OpenPGP: 1024D/ED7DAEA6 |