Expected: When /usr/portage is symlink to /var/portage, then portage (emerge) should handle everything as if /var/portage were actually present at /usr/portage. Actual: While portage-2.0.x handles this correctly, portage-2.1.x does not. Portage instead generates a cache for /var/portage, but then operates on /usr/portage. Steps to reproduce: (1) system with portage-2.0.x (2) move /usr/portage to /var/portage (3) symlink /usr/portage to /var/portage, as suggested by 2.0.x portage documentation over 1 year ago. (4) set portage dir in /etc/make.conf as /usr/portage, because any other dir could break emerge From /etc/make.conf: PORTDIR=/usr/portage (5) everything works dandy! (6) upgrade to portage-2.1.x (7) run 'emerge --metadata' ---> emerge generates cache in /var/cache/edb/dep/var/portage/ (9) run 'emerge -pvu world' ---> emerge attempts to use cache in /var/cache/edb/dep/usr/portage/ ---> emerge runs as slow as if no cache is present! Workaround: (1) Instead of using symlink, use 'mount -o bind'. (2) Optionally delete /var/cache/edb/dep (3) run 'emerge --metadata'
(In reply to comment #0) > ---> emerge generates cache in /var/cache/edb/dep/var/portage/ > (9) run 'emerge -pvu world' > ---> emerge attempts to use cache in /var/cache/edb/dep/usr/portage/ > ---> emerge runs as slow as if no cache is present! That's interesting. ANyway, you should set PORTDIR="/var/portage" in make.conf (see make.conf.example and `man 5 make.conf`).
The problem is that the paths of the eclasses in the metadata had /usr/portage instead of /var/portage. It is fixed in svn r3666.
This has been released in 2.1.1_pre1-r3.
*** Bug 140290 has been marked as a duplicate of this bug. ***
This fix should be included in 2.1-r2 if we do another stable revbump.
