This seems like changed behavior to me (meaning portage didn't do it before). I am going to be fighting the ridiculous spidermonkey dependency in polkit until my dying breath (meaning I am going to use 0.104 until it absolutely does not work any more, and then I may drop the *kits altogether). Anyway, there was a recent change in consolekit (0.4.5_p20120320-r1) without a revision bump that changed the minimum version of policykit to 0.110. "policykit? ( >=sys-auth/polkit-0.110 )" So I added the added the ebuild to a local repository and reverted that line. However, when I ran emerge -Dpu world, portage still wanted to do the upgrade. I tried emerge -p consolekit, and portage (correctly) picked up the new ebuild in the local repository. I then tried emerge -ep world, and portage said it would install consolekit from the local repository, and not demand an update to polkit. After an emerge consolekit (which changed the installed version from the gentoo repository to the local repository), then emerge -Dpu world no longer wanted to update polkit. This behavior just feels wrong to me. I believe that portage should either consider the dependencies in the ebuild at the time it was installed OR the dependencies in the ebuild that would be re-installed. The current situation also leads to emerge -e world coming up with different packages than emerge -Du world, which also doesn't seem correct.
How about if we add a new option call --changed-repo that's like --changed-use, but for changed repos instead of changed USE? You'd be able to put it in the EMERGE_DEFAULT_OPTS variable in make.conf if you want it enabled by default.
(In reply to comment #1) > How about if we add a new option call --changed-repo that's like > --changed-use, but for changed repos instead of changed USE? You'd be able > to put it in the EMERGE_DEFAULT_OPTS variable in make.conf if you want it > enabled by default. Sounds reasonable to me.
*** This bug has been marked as a duplicate of bug 347269 ***
