I've modifyed sys-libs/db ebuild as in comment #18 bug 132690 and during emerge I saw the following error messages: camobap db # emerge =sys-libs/db-3* Calculating dependencies... done! >>> Emerging (1 of 1) sys-libs/db-3.2.9-r11 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking db-3.2.9.tar.gz ;-) !!! ERROR: Couldn't find a VM dep !!! ERROR: Couldn't find a VM dep !!! ERROR: sys-libs/db-3.2.9-r11 failed. Call stack: ebuild.sh, line 1555: Called dyn_setup ebuild.sh, line 667: Called pre_pkg_setup java-pkg-opt-2.eclass, line 50: Called java-pkg-opt-2_pkg_setup java-pkg-opt-2.eclass, line 37: Called java-pkg_init java-utils-2.eclass, line 1410: Called java-pkg_switch-vm java-utils-2.eclass, line 1797: Called java-pkg_javac-args java-utils-2.eclass, line 1214: Called die !!! Could not find valid -source/-target values !!! If you need support, post the topmost build error, and the call stack if relevant. !!! When you file a bug report, please include the following information: GENTOO_VM=None CLASSPATH="." JAVA_HOME="" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info [sniped the above errors begining with !!!] [and another time sniped the above errors begining with !!!] * Using: sun-jdk-1.4 >>> Unpacking source... >>> Unpacking db-3.2.9.tar.gz to /home/misc/porttmp/portage/db-3.2.9-r11/work * Applying patch.3.2.9.1 ... [ ok ] * Applying patch.3.2.9.2 ... [ ok ] * Applying db-3.2.9-fix-dep-link.patch ... [ ok ] * Applying db-3.2.9-jarlocation.patch ... [ ok ] * Applying db-3.2.9-java15.patch ... [ ok ] * Using GNU config files from /usr/share/libtool * Updating dist/config.sub [ ok ] * No config.guess found in /home/misc/porttmp/portage/db-3.2.9-r11/work/db-3.2.9, skipping ... >>> Source unpacked. [Again completly the same error messages!] >>> Compiling source in /home/misc/porttmp/portage/db-3.2.9-r11/work/db-3.2.9 ... * Configuring db-3.2.9 (static)... creating cache ./config.cache checking for a BSD compatible install... /bin/install -c checking host system type... i686-pc-linux-gnu [and so on] The problem is that with new jave system we should explicitly state virtual/jdk version number. So quick fix to this problem is: - java? ( virtual/jdk )" + java? ( >=virtual/jdk-1.3 )" Seem that this is feature, and there were were attempts to document this: http://www.gentoo.org/proj/en/java/java-devel.xml#doc_chap4 But IMO [] ordinary means the optional components, thus I'd say if this is feature this should be stated explicitly! Another problem is that inside eclass (java-utils-2) you are using die in subshell, and the result is that the process actually does not die but stay alive. See (about die and subshell): http://devmanual.gentoo.org/ebuild-writing/error-handling/index.html I'm not sure that all above are bugs, but I think it's better to fix the issues somehow :) TIA
(In reply to comment #0) > Seem that this is feature, and there were were attempts to document this: > http://www.gentoo.org/proj/en/java/java-devel.xml#doc_chap4 > But IMO [] ordinary means the optional components, thus I'd say if this is > feature this should be stated explicitly! Uhm, that [] is clearly not optional, as >=virtual/{jre,jdk} is NOT a valid atom (despite broken repoman that doesn't utter a word about such broken deps) ;o)
(In reply to comment #1) > Uhm, that [] is clearly not optional, as >=virtual/{jre,jdk} is NOT a valid > atom (despite broken repoman that doesn't utter a word about such broken deps) > ;o) Sure and that contradiction adds additional questions. IMHO something something like: >=virtual/jre-minimal.version or =virtula/jre-version is much more clear. And I'd like to read somewhere that specification of version is required. :)
Added that the atoms must have a version for jre and jdk. You should also open a separate bug for the subshell issue.
