After doing # emerge rsync # emerge -pu world the latest emerge of PHP 4.3.0 borks because it can't find blackdown java. See my comment #7 in bug 15816 for particulars. Note: Both the latest version of blackdown-jdk-1.4.1 and php-4.3.0 came up for emerging in 'emerge -pu world'. Blackdown appeared to emerge to completion successfully while the 'emerge -pu world' borked on php. Before reporting this I did search both 'blackdown' and 'java' as search terms. Reproducible: Always Steps to Reproduce: Expected Results: Emerge of blackdown-jdk should have updated the java config environmental variables correctly.
I can verify this happening as well. It is repaired by tweaking java-config manually but this should be done in the ebuild automagically.
My work machine has the same identical situation. However, since I don't have apache and php on it, php didn't have the opportunity to 'blow up' on me. I suspect that all the other packages I've emerged recently did not have java as a dependency.
I've read the manpage for java-config. Unfortunately, there are no examples. My attempts at using java-config are: dragon root # java-config --list-available-packages [pdflib] "" (/usr/share/pdflib/package.env) dragon root # java-config --list-available-vms [blackdown-jdk-1.4.1] Blackdown JDK 1.4.1 (/etc/env.d/java/20blackdown-jdk-1.4.1) dragon root # java-config --set-system-vm blackdown-jdk-1.4.1 Usage: java-config [OPTIONS] [LIBRARIES] Options: [--javac] [--java] [--jar] [--jdk-home] [--jre-home] [--java-version] [--classpath[=package1,package2,...]] [--full-classpath=package1,package2,...] [--exec=filename] [--list-available-packages] [--list-available-vms] [--set-system-vm=<vm-id>] [--set-user-vm=<vm-id>] [--set-system-classpath=package1,package2,...] [--set-user-classpath=package1,package2,...] [--clean-system-classpath] Using /opt/blackdown-jdk-1.4.1_beta dragon root # java-config --set-system-vm /etc/env.d/java/20blackdown-jdk-1.4.1 Usage: java-config [OPTIONS] [LIBRARIES] Options: [--javac] [--java] [--jar] [--jdk-home] [--jre-home] [--java-version] [--classpath[=package1,package2,...]] [--full-classpath=package1,package2,...] [--exec=filename] [--list-available-packages] [--list-available-vms] [--set-system-vm=<vm-id>] [--set-user-vm=<vm-id>] [--set-system-classpath=package1,package2,...] [--set-user-classpath=package1,package2,...] [--clean-system-classpath] Using /opt/blackdown-jdk-1.4.1_beta dragon root # java-config --set-system-vm /opt/blackdown-jdk-1.4.1 Usage: java-config [OPTIONS] [LIBRARIES] Options: [--javac] [--java] [--jar] [--jdk-home] [--jre-home] [--java-version] [--classpath[=package1,package2,...]] [--full-classpath=package1,package2,...] [--exec=filename] [--list-available-packages] [--list-available-vms] [--set-system-vm=<vm-id>] [--set-user-vm=<vm-id>] [--set-system-classpath=package1,package2,...] [--set-user-classpath=package1,package2,...] [--clean-system-classpath] Using /opt/blackdown-jdk-1.4.1_beta dragon root # As you can see - I don't understand how to tell it what libraries to use. (call me Dufus User) I did look at /usr/bin/java-config script. I was strongly reminded of my lacks as a bash script writer. Looking at the script did not clue me in as to the format to be used for setting the system vm. :-( Please help. I'd like to be able to properly work around this problem. :-)
Guy, I found this problem as well. I found the command line you are looking for in the /etc/env.d/20java startup file at the top in the comments. This should indeed be done by emerge. I had the exact same problem. 1) I have no blackdown-jre installed. Just blackdown-jdk 2) I did an emerge rsync 3) emerge -u world 4) blackdown-jdk 1.4.1 final was installed 5) env.d/20java was not updated so everything points to a nearly empty directory /opt/blackdown-jdk-1.4.1_beta because portage removed it.
I cheated. I copied the contents of /etc/env.d/java from a new machine I recently built to the machine I was having problems with. Since I use the same version of blackdown java and ant for all of my machines, copying was feasible. Apparently, this issue may be fixed as my newer machine was correctly configured. However, if the problem is caused during an _update_ of java, then it might still be possible to encounter a problem in the future. In the meantime, all my systems are working correctly so I feel this bug can be closed. Please note: FWIW - I still have some problems understanding the man page for java-config. I was unable to successfully use it to solve my problem.
It seems the new ebuild runs java-config automagically, and the 'proper' syntax for java-config is this: java-config --set-system-vm=blackdown-jdk-1.4.1 you were missing the = :)
