|Summary:||kdelibs fails to build and git and icedtea are dropped due to unsatisfied dependency|
|Product:||Portage Development||Reporter:||Dennis Schridde <devurandom>|
|Component:||Core - Dependencies||Assignee:||Portage team <dev-portage>|
|Severity:||normal||CC:||1i5t5.duncan, asturm, graham, jarausch|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||373807, 445274|
Description Dennis Schridde 2011-12-03 19:59:13 UTC
Both dev-vcs/git and dev-java/icedtea were dropped due to unsatisfied dependencies, while only kde-base/kdelibs seems to have failed. Output attached. Even if this turns out to be not actually a bug, it would be nice if emerge would display which unsatisfied dependency caused the drop, so one could see what portage "thinks". Reproducible: Always
Comment 2 Zac Medico 2011-12-03 21:45:35 UTC
Please post a log for the following command: emerge --pretend --emptytree --debug dev-vcs/git dev-java/icedtea &> debug.log
Comment 4 Zac Medico 2011-12-04 19:49:46 UTC
(In reply to comment #3) > Created attachment 294781 [details] > debug.log The log shows that kde-base/kdelibs-4.7.4 is pulled into the graph, so that explains why git and icedtea would get dropped if kdelibs failed to build.
Comment 5 Dennis Schridde 2011-12-04 19:59:37 UTC
Why does the installed version (4.7.3) not satisfy this dependency?
Comment 6 Zac Medico 2011-12-04 20:16:45 UTC
(In reply to comment #5) > Why does the installed version (4.7.3) not satisfy this dependency? Maybe it does. However, when the --keep-going code encounters an unsatisfied dependency, it traverses up the edges of the graph removing things like dev-vcs/git and dev-java/icedtea, even though the edges that it traverses aren't necessarily the only possible way to satisfy the dependencies that the edges represent.
Comment 7 Zac Medico 2012-03-31 17:32:28 UTC
*** Bug 410311 has been marked as a duplicate of this bug. ***
Comment 8 Zac Medico 2012-07-17 20:07:46 UTC
*** Bug 426824 has been marked as a duplicate of this bug. ***
Comment 9 Andreas Sturmlechner 2012-07-18 23:47:34 UTC
I just got the same bug where opencv, portage, gtk+, firefox etc. were dropped because cups-filters-9999 failed to build.
Comment 10 Duncan 2012-12-28 23:31:29 UTC
(In reply to comment #6) > [W]hen the --keep-going code encounters an unsatisfied > dependency, it traverses up the edges of the graph removing things like > dev-vcs/git and dev-java/icedtea, even though the edges that it traverses > aren't necessarily the only possible way to satisfy the dependencies that > the edges represent. Zac, I've wondered for awhile about a --really-keep-going, or a --keep-going-recursive option or the like, which would keep track of how many packages were merged in a run as well as whether any failed, and retry again and again until no further packages were merged. The historic case where such an option would be useful, would be kde, which I often merge the day upstream releases while it's still in the gentoo/kde overlay and a few of the complex interdependendencies haven't been worked out yet. Often, something would fail to merge, but then, after everything else merged that was possible, it would merge on a retry. This is generally a result of one of two factors, (1) an entirely random (from the user perspective, flameeyes could probably explain it in one of his blog posts) parallel-make job-tokens error (13 job tokens when there should only be 12, etc), or (2) an unspecified dependency that eventually ends up being pulled in by some other package, so the package that failed can now build. In either case, an "I REALLY mean keep-going, try again and again until NOTHING else is successfully merged" option could be quite useful. It would also nicely solve the apparently new problem in bug #448176 (in the see also, which actually brought me here), and might help solve this one. (I'm not sufficiently sure of the technical nature of this one to be sure, but I'm replying to your comment on --keep-going here, so...) If you'd like, tell me to file a new enhancement bug for this, or to take further discussion of it over to bug #448176, and I will.
Comment 11 Zac Medico 2012-12-28 23:39:04 UTC
(In reply to comment #10) > In either case, an "I REALLY mean keep-going, try again and again until > NOTHING else is successfully merged" option could be quite useful. > > If you'd like, tell me to file a new enhancement bug for this, or to take > further discussion of it over to bug #448176, and I will. I don't think we need a separate option. We just need to fix --keep-going to handle these cases where it's failing.