+++ This bug was initially created as a clone of Bug #224823 +++ While this bug started as that clone, it's really the result of the fix for the the above bug. The bug trigger is that I'm running a unified /usr /, with: /usr -> ./ Portage actually handles that well in general, and this is the first problem I've come across as a result, due not to portage but to bad assumptions in a specific ebuild. Now I have no dircolors! An investigation pointed me at the line in the ebuild that deletes it, and the corresponding bug cloned above. =:^( Suggested fix: Use readlink or realpath to resolve both /usr/bin/dircolors and /bin/dircolors and only continue with the rm if they are not the same file. Using realpath, the test clause to add before doing the rm could look like this: [[ $(realpath /usr/bin/dircolors) != $(realpath /bin/dircolors) ]] &&
we've probably outlived that migration codepath now, so we can just delete it
should be all set now in the tree; thanks for the report! Commit message: Drop old migration logic as we have moved way beyond it and it causes issues with /usr merge http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.22-r1.ebuild?r1=1.1&r2=1.2