Summary: | icedtea6-bin required for emerging swt or xulrunner .tbz2's ?? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Friedt <chrisfriedt> |
Component: | [OLD] Java | Assignee: | Java team <java> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | boltomli, dev-portage |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christopher Friedt
2009-10-23 15:36:08 UTC
(In reply to comment #0) > have a virtual/{jdk,jre} installed. This happens in spite of the fact that I > already have dev-java/sun-jdk-1.6 installed on the build and host machines. > ... > 1.install dev-java/sun-jdk-1.4 So, is it a sun-jdk-1.4 or sun-jdk-1.6? Anyway, in swt-3.5 there's a RDEPEND=">=virtual/jre-1.4", so portage probably selects jre-1.6. jre-1.6.0 has RDEPEND="|| ( =virtual/jdk-1.6.0* <and some actual jre's>" so portage probably selects the jdk-1.6. The first alternative in jdk-1.6 is dev-java/icedtea6-bin. Due to this multiple indirection, portage probably does not search all possible variants. If you have sun-jdk-1.4 installed, then it does not search the analogical path through jre-1.4 and jre-1.6. If you have sun-jdk-1.6 installed then it's stranger, it goes to the correct path though jre-1.6 and jdk-1.6 and should select sun-jdk-1.6 because it's installed, despite icedtea6-bin being the first alternative there. CC'ing dev-portage :) (In reply to comment #1) > analogical path through jre-1.4 and jre-1.6 I meant through jre-1.4 and jdk-1.4 Can you please try it with portage-2.1.7.1 to see if it makes any difference? Also, please post --debug --pretend output for the commands which are behaving poorly. (In reply to comment #1) > Due to this multiple indirection, portage probably does not search all possible > variants. It seems like something else is wrong because that's already handled since bug 141118. Marking this one as duplicate in favor of the newer one wrt portages resolver and handling of jre/jdk virtuals. *** This bug has been marked as a duplicate of bug 382421 *** |