Summary: | kdelibs fails to build and git and icedtea are dropped due to unsatisfied dependency | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 1i5t5.duncan, asturm, graham, jarausch |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=448176 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 373807, 445274 | ||
Attachments: |
emerge output
debug.log |
Description
Dennis Schridde
2011-12-03 19:59:13 UTC
Created attachment 294633 [details]
emerge output
Please post a log for the following command: emerge --pretend --emptytree --debug dev-vcs/git dev-java/icedtea &> debug.log Created attachment 294781 [details]
debug.log
(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. Why does the installed version (4.7.3) not satisfy this dependency? (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. *** Bug 410311 has been marked as a duplicate of this bug. *** *** Bug 426824 has been marked as a duplicate of this bug. *** I just got the same bug where opencv, portage, gtk+, firefox etc. were dropped because cups-filters-9999 failed to build. (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. (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. I think this has the same cause as bug 448176, which should be fixed in 2.1.11.39 and 2.2.0_alpha150. |