1 |
On 04/12/2010 10:17 AM, James Cloos wrote: |
2 |
>>>>>> "ZM" == Zac Medico <zmedico@g.o> writes: |
3 |
> |
4 |
> ZM> On 04/06/2010 07:22 AM, James Cloos wrote: |
5 |
>>>>>>>> "ZM" == Zac Medico <zmedico@g.o> writes: |
6 |
>>> |
7 |
> ZM> You can configure eclass override behavior via eclass-overrides in |
8 |
> ZM> /etc/portage/repos.conf, as documented in `man portage`. |
9 |
>>> |
10 |
>>> ,----< From that manpage > |
11 |
>>> | When using eclass-overrides, due to bug #276264, you must ensure that |
12 |
>>> | your portage tree does not contain a metadata/cache/ directory. |
13 |
>>> `---- |
14 |
>>> |
15 |
>>> Which translates into "eclass-orderrides are completely and entirely |
16 |
>>> useless, so don't bother. |
17 |
> |
18 |
> ZM> Well, it's roughly equivalent to the old default behavior (which you |
19 |
> ZM> apparently preferred). However, the issue is now complicated by the |
20 |
> ZM> fact that FEATURES=metadata-transfer is disabled by default, so when |
21 |
> ZM> portage goes to pull cache directly from metadata/cache/, it won't |
22 |
> ZM> be able to validate eclass changes since there are no eclass |
23 |
> ZM> timestamps saved inside metadata/cache/. |
24 |
> |
25 |
> Portage does not need to validate eclass changes. |
26 |
|
27 |
Then how do you propose that it handles metadata changes that are |
28 |
attributed to eclass changes? For example, see the issue they had |
29 |
with vmware.eclass changes in this bug: |
30 |
|
31 |
http://bugs.gentoo.org/show_bug.cgi?id=139134 |
32 |
-- |
33 |
Thanks, |
34 |
Zac |