On 11/09/2013 22:46, Timur Aydin wrote: > On 09/11/13 23:13, Alan McKinnon wrote: >> I can't reproduce that fault here, and google hits on the matter seem to >> point towards stale metadata referencing eclasses that no longer exist. >> I have a hunch you do not have valid metadata for your local overlay, so >> I suggest: >> >> 1. delete the eclass directory from your overlay, run "emerge >> --metadata" and emerge samba again. See what that does. > > I have tried this, and the same problem happened, where emerge > complained that pam.eclass wasn't found. > >> 2. Set PORTDIR_CACHE_METHOD and/or OVERLAY_CACHE_METHOD explicitly in >> make.conf, the best reference for these is in the eix man page > > While reading up on the various methods in the eix man page, I started > to wonder whether a setting in /usr/local/portage/metadata/layout.conf > was causing this problem. When testing, layout.conf had only a single > entry, which was: > > masters = > > I remembered an error message from portage a while ago, which suggested > setting this to "gentoo" for backward compatibility. I tried that, and > the problem went away :) I was able to emerge samba from the overlay > successfully. Does this make sense?
/headbang :-) Yes of course, it make a great deal of sense now. Basically, your local overlay had no idea where the parent portage tree is or how to find it so couldn't find the eclass directory. As I understand it, this information used to be hard-coded magic and overlays would "just know where to look". Since recently, you have to configure it explicitly and not use hidden super-magic. You would have been getting confusing messages in emerge output about a faulty masters setting for overlays, pity we didn't spot that up front. Double pity that there wasn't a clear message or news item about what the error meant and the impact.... -- Alan McKinnon alan.mckin...@gmail.com
