On 04/12/2010 10:17 AM, James Cloos wrote:
>>>>>> "ZM" == Zac Medico <firstname.lastname@example.org> writes:
> ZM> On 04/06/2010 07:22 AM, James Cloos wrote:
>>>>>>>> "ZM" == Zac Medico <email@example.com> writes:
> ZM> You can configure eclass override behavior via eclass-overrides in
> ZM> /etc/portage/repos.conf, as documented in `man portage`.
>>> ,----< From that manpage >
>>> | When using eclass-overrides, due to bug #276264, you must ensure that
>>> | your portage tree does not contain a metadata/cache/ directory.
>>> Which translates into "eclass-orderrides are completely and entirely
>>> useless, so don't bother.
> ZM> Well, it's roughly equivalent to the old default behavior (which you
> ZM> apparently preferred). However, the issue is now complicated by the
> ZM> fact that FEATURES=metadata-transfer is disabled by default, so when
> ZM> portage goes to pull cache directly from metadata/cache/, it won't
> ZM> be able to validate eclass changes since there are no eclass
> ZM> timestamps saved inside metadata/cache/.
> Portage does not need to validate eclass changes.
Then how do you propose that it handles metadata changes that are
attributed to eclass changes? For example, see the issue they had
with vmware.eclass changes in this bug: