I've had a report from user for who portage repeatedly rebuilt a bunch of Python packages. The rebuilding stopped once he installed python-exec:2 and rebuilt them afterwards. While I don't have any solid proof, I suspect that portage triggered the 'slot upgrade' rebuild for python-exec's revdeps before python-exec was updated itself. Since the user hasn't synced for a while before the issue, it may be also related to 'python-exec' dep in the eclass changing to 'python-exec:=', so possibly portage trying to use the deps from the tree rather than vardb. Sadly, the user can't reproduce it anymore so if you can't find out what happened via guessing/code reading, we'll have to wait for someone else to have a similar issue.
from my observation, this happens only if both python-exec installed (:0 and :2) using either one, solving loop rebuilds.
I had just :0 installed when I got the issue. After installing :2 and rebuilding the entire rdeps set a few times (must have been 3-4) it seems to have disappeared.
rebuilding 3-4 time same package is not a solution. IT should NOT cause any unnecessary rebuilds at all. This looks like rather misdesigned package, python-exec. it shouldn't be slotted
(In reply to Oleg from comment #3) > rebuilding 3-4 time same package is not a solution. IT should NOT cause any > unnecessary rebuilds at all. This looks like rather misdesigned package, > python-exec. it shouldn't be slotted Every package has a right to be slotted. The design is correct, and the dependencies are correct. What is not correct is portage behavior. I'm sorry for that but you have no right to offend me and you clearly don't understand the issue.
*** Bug 486910 has been marked as a duplicate of this bug. ***
I can confirm that the rebuilds stopped by manually emerging python-exec:2.
If it's a problem with the dependency change in the eclass, then the --dynamic-deps=n option should resolve the problem.
I can reproduce the problem and I think I found the problem. What you need is dev-lang/python-exec:0 installed but not :2. Then something in your merge list needs to depend on dev-lang/python-exec and nothing that forces a specific slot of dev-lang/python-exec (if this exists at all). What then happens is that emerge wants to use the installed dev-lang/python-exec:0 to satisfy dependencies. This would be fine, except that emerge then notices that there is an update to :2 and if there are slot operator deps on dev-lang/python-exec it suspects that these deps prevented the update from :0 to :2. To circumvent these deps, it then starts to mask each installed package that has a slot operator dep on dev-lang/python-exec and backtracks. And it does this one by one. Since tons of packages depend on dev-lang/python-exec this process virtually takes forever. But since there is a hardcoded limit for backtracking steps, the process is interrupted at some point. But at this point only some packages are scheduled for rebuild and some are not. Because of this, the update to dev-lang/python-exec:2 is still not in the merge list. Now I only need to find a fix...
This fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5842e87872fd738cdfc7d0698463f1d11ffe5dee
*** Bug 491518 has been marked as a duplicate of this bug. ***
*** Bug 489704 has been marked as a duplicate of this bug. ***
*** Bug 486438 has been marked as a duplicate of this bug. ***
*** Bug 492564 has been marked as a duplicate of this bug. ***
Another fix is in git. Rebuilds were properly scheduled, but in some cases the package that caused the rebuild might not get installed, rendering the rebuilds point less. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=8a23eb70eb289fc84d77754447b5f9a84b94b4e1
*** Bug 493350 has been marked as a duplicate of this bug. ***
