Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 486580 - sys-apps/portage: seems to rebuild python-exec revdeps 'too early'
Summary: sys-apps/portage: seems to rebuild python-exec revdeps 'too early'
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 486438 486910 489704 491518 492564 493350 (view as bug list)
Depends on:
Blocks: 155723 484436
  Show dependency tree
 
Reported: 2013-09-30 14:21 UTC by Michał Górny
Modified: 2014-01-06 00:38 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 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 archtester Gentoo Infrastructure gentoo-dev Security 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 archtester Gentoo Infrastructure gentoo-dev Security 2013-10-09 05:26:23 UTC
*** Bug 486910 has been marked as a duplicate of this bug. ***
Comment 6 Chris Reffett (RETIRED) gentoo-dev Security 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 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. ***