Bug 486580 – sys-apps/portage: seems to rebuild python-exec revdeps 'too early'

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Michał Górny 2013-09-30 14:21:32 UTC]

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.

[Comment 1 Oleh 2013-09-30 17:13:18 UTC]

from my observation, this happens only if both python-exec installed (:0 and :2)
using either one, solving loop rebuilds.

[Comment 2 gentoo 2013-09-30 17:16:20 UTC]

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.

[Comment 3 Oleh 2013-10-01 04:45:06 UTC]

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

[Comment 4 Michał Górny 2013-10-01 17:12:43 UTC]

(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.

[Comment 5 Michał Górny 2013-10-09 05:26:23 UTC]

*** Bug 486910 has been marked as a duplicate of this bug. ***

[Comment 6 Chris Reffett (RETIRED) 2013-10-15 00:49:21 UTC]

I can confirm that the rebuilds stopped by manually emerging python-exec:2.

[Comment 7 Sebastian Luther (few) 2013-11-22 11:28:14 UTC]

If it's a problem with the dependency change in the eclass, then the --dynamic-deps=n option should resolve the problem.

[Comment 8 Sebastian Luther (few) 2013-11-25 18:42:06 UTC]

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...

[Comment 9 Sebastian Luther (few) 2013-11-26 13:57:40 UTC]

This fixed in git:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5842e87872fd738cdfc7d0698463f1d11ffe5dee

[Comment 10 Sebastian Luther (few) 2013-11-26 13:58:57 UTC]

*** Bug 491518 has been marked as a duplicate of this bug. ***

[Comment 11 Sebastian Luther (few) 2013-11-26 14:00:29 UTC]

*** Bug 489704 has been marked as a duplicate of this bug. ***

[Comment 12 Sebastian Luther (few) 2013-11-26 21:01:59 UTC]

*** Bug 486438 has been marked as a duplicate of this bug. ***

[Comment 13 Sebastian Luther (few) 2013-11-27 06:10:27 UTC]

*** Bug 492564 has been marked as a duplicate of this bug. ***

[Comment 14 Sebastian Luther (few) 2013-12-02 06:20:18 UTC]

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

[Comment 15 Sebastian Luther (few) 2013-12-05 15:02:01 UTC]

*** Bug 493350 has been marked as a duplicate of this bug. ***