# nice revdep-rebuild -i -p * Configuring search environment for revdep-rebuild * Working directory expected to be /tmp/revdep-rebuild-root, but it is /crypt/tmp/revdep-rebuild-root # ls -la /tmp lrwxrwxrwx 1 root root 9 Nov 17 2005 /tmp -> crypt/tmp # head -n 470 /usr/bin/revdep-rebuild | tail -n 12 # Dies when it can't change directories cd() { if builtin cd -P "$@"; then if [[ $1 != $PWD ]]; then # Some symlink malfeasance is going on die 1 "Working directory expected to be $1, but it is $PWD" fi else die 1 "Unable to change working directory to '$@'" fi } ## I have some directories symlinked to dirs in /crypt (/tmp /var /home /etc/racoon and others). I found this forum thread about this problem but I couldn't find a filed bug: http://forums.gentoo.org/viewtopic-t-700189-start-0-postdays-0-postorder-asc-highlight-directory+expected.html The fix suggested in that thread (bind mounts) is not practical due to the large number of dirs I've symlinked. No other program I've used has ever complained about this use of symlinks, and I'm not sure what problem is being solved here.
Unfortunately, I don't have an answer to you other than to bind mount /var/cache once you have installed gentoolkit-0.2.4_rc6 or higher. The changes were mandated by the security team in the resolving of bug #203414
*** Bug 239405 has been marked as a duplicate of this bug. ***
*** Bug 242534 has been marked as a duplicate of this bug. ***
Hit by the problem on stable amd64. /tmp is already a 'mount bind' to the actual tmp dir, but the problem is still there.
/var/cache is hardcoded in /usr/bin/revdep-rebuild (not even a var name at the beginning of the file). Fortunately though, it only appears in two lines. Changing those to my actual path seems to fix the problem. You might want to try this if you are hit by this ugly bug too.
