cat 20java # Autogenerated by java-config # Command: --set-system-vm=sun-jre-bin-1.5.0.06 PATH="/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws" ROOTPATH="/opt/sun-jre-bin-1.5.0.06/bin:/opt/sun-jre-bin-1.5.0.06/javaws" LDPATH="/opt/sun-jre-bin-1.5.0.06/lib/i686/:/opt/sun-jre-bin-1.5.0.06/lib/i686/native_threads/:/opt/sun-jre-bin-1.5.0.06/lib/i686/xawt/:/opt/sun-jre-bin-1.5.0.06/lib/i686/server/" # VERSION="Sun JRE 1.5.0.06" MANPATH=${MANPATH}:/opt/sun-jre-bin-1.5.0.06/man JRE_HOME=/opt/sun-jre-bin-1.5.0.06 JAVA_HOME=/opt/sun-jre-bin-1.5.0.06 --- That ${MANPATH} will never get expanded, env-update doesn't behave like that and all the stuff there is cumulative. As it is, I end up with: $ echo $MANPATH /usr/local/share/man:/usr/share/man:/usr/share/binutils-data/i686-pc-linux-gnu/2.17.50.0.5/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man:/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man:${MANPATH}:/opt/sun-jre-bin-1.5.0.06/man:/etc/java-config/system-vm/man/:/usr/qt/3/doc/man:/opt/vmware/server/man which is obviously wrong.
envfile of sun-jre-bin-1.5.0.06 in $FILESDIR looks ok, so it must be added by java-config... or is it also in /etc/env.d/java/20sun-jre-bin-1.5.0.06 ? What version of java-config-1 is that?
# qlist -CIv java-config dev-java/java-config-1.3.7 dev-java/java-config-2.0.30 dev-java/java-config-wrapper-0.12
Your /etc/env.d/20java must've been created with some older java-config-1, or dunno. java-config-1.3.7 won't let you set sun-jre-bin-1.5.0.06 as system VM, because it's not gen-2 aware VM.
Well I really have absolutely no clue what installed/created this file, if it says autogenerated by java-config I assume it's been autogenerated by java-config. Plus I don't even have 1.5.0.06 installed. [ebuild R ] dev-java/sun-jre-bin-1.5.0.08-r1 USE="X alsa nsplugin" 0 kB Maybe java-config should wipe this pointless file then? Or is that supposed to be there?
The file is supposed to be there. It is how the legacy eclasses figure out VM should be used for building. I bet if you ran java-check-environment, it'd tell you that your generation-1 system vm needs to be updated. So, it should be set to a 1.4 JDK. If you don't use any java stuff aside from jre, you can safely delete the file.
(In reply to comment #5) > I bet if you ran java-check-environment, it'd tell you that your generation-1 > system vm needs to be updated. So, it should be set to a 1.4 JDK. I don't have any JDK, or anything 1.4 here, just the recent eclass update forced java-config-1 on me again. <snip> # java-check-environment * === Java Environment Checker === * The purpose of this script is to check the sanity of your Java Environment. * We have significantly changed and improved the way Java is handled in many respects. * Please refer to http://www.gentoo.org/proj/en/java/java-upgrade.xml for details * Checking vm_environment_files ... [ ok ] * Checking user_settings ... * Running as root. Don't need to check user settings. [ ok ] * Checking generation_1_system_vm ... * No Generation-1 System VM is set! (no java-config-1 -f output) * Run 'java-config-1 -L' to see a list of available VMs * Then run 'java-config-1 -S <VM choice>' * Then run 'env-update && source /etc/profile [ !! ] * Some problems were found. Please follow the instructions above, and rerun java-check-environment </snip> > If you don't use any java stuff aside from jre, you can safely delete the file. Sounds like a good idea, just still puzzled how it got created and why it wasn't ever updated. :)
(In reply to comment #6) > (In reply to comment #5) > I don't have any JDK, or anything 1.4 here, just the recent eclass update > forced java-config-1 on me again. recent java-config-1 can't be responsible for this > > If you don't use any java stuff aside from jre, you can safely delete the file. > > Sounds like a good idea, just still puzzled how it got created and why it > wasn't ever updated. :) Must have been created when there was only gen-1 and you installed sun-jre-bin-1.5.0.06. It was never updated because you likely never installed a 1.4 JDK and set it as gen-1 system VM. So just delete it. The MANPATH problem doesn't seem to be present in current java-config and JDK/JRE env files.
Well, I just fixed the stuff manually because I didn't find a way to regenerate it with JRE-1.5 only installed. Deleting it is a less-than-ideal solution because none of the manpages is accessible then, plus JAVA_HOME env variable is not set then. :)
You're right about MANPATH, but not JAVA_HOME. It gets set by /etc/profile.d/java-config-2.sh. Should be easy enough to append to the MANPATH there as well.
(In reply to comment #9) > You're right about MANPATH, but not JAVA_HOME. It gets set by > /etc/profile.d/java-config-2.sh. Should be easy enough to append to the MANPATH > there as well. > I am having a similar problem with java-config-1. I am trying to use sun-jdk-1.5 for my gen-2 jvm. The problem is, my gen-1 jdk (blackdown-1.4.x) keeps getting added to my $PATH env-var so I can't easily USE java 1.5. I have tried everything (even removing /etc/env.d/20java) but that results in a non-sane java environment, as checked by java-check-environment. Is this a bug that java-config-2 doesn't update the PATH to your jvm (and hence, javac and all that?) my /etc/env.d/20java (after running java-config --set-system-vm=sun-jdk-1.5) # Autogenerated by java-config # Command: --set-system-vm=blackdown-jdk-1.4.2 LDPATH=/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/:/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/native_threads/:/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/classic/:/opt/blackdown-jdk-1.4.2.03/jre/lib/i386/server/ JDK_HOME=/opt/blackdown-jdk-1.4.2.03 JAVAC=/opt/blackdown-jdk-1.4.2.03/bin/javac GENERATION=2 ROOTPATH=/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin VMHANDLE=blackdown-jdk-1.4.2 # VERSION=Blackdown JDK 1.4.2.03 MANPATH=/opt/blackdown-jdk-1.4.2.03/man PATH=/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin JAVA_HOME=/opt/blackdown-jdk-1.4.2.03
(In reply to comment #10) > Is this a bug that java-config-2 doesn't update the PATH to your jvm (and > hence, javac and all that?) No, java-config-2 installs wrappers for all the commands (java, javac...) in /usr/bin/ which is before the gen-1 VM path (thus overrides it).
# Autogenerated by java-config # Command: --set-system-vm=sun-jre-bin-1.5.0.08 PATH="/opt/sun-jre-bin-1.5.0.08/bin:/opt/sun-jre-bin-1.5.0.08/javaws" ROOTPATH="/opt/sun-jre-bin-1.5.0.08/bin:/opt/sun-jre-bin-1.5.0.08/javaws" LDPATH="/opt/sun-jre-bin-1.5.0.08/lib/i686/:/opt/sun-jre-bin-1.5.0.08/lib/i686/native_threads/:/opt/sun-jre-bin-1.5.0.08/lib/i686/xawt/:/opt/su n-jre-bin-1.5.0.08/lib/i686/server/" # VERSION="Sun JRE 1.5.0.08" MANPATH=/opt/sun-jre-bin-1.5.0.08/man JRE_HOME=/opt/sun-jre-bin-1.5.0.08 JAVA_HOME=/opt/sun-jre-bin-1.5.0.08 # emerge -pv sun-jre-bin [ebuild R ] dev-java/sun-jre-bin-1.5.0.09-r1 USE="X alsa nsplugin" 0 kB So, now the above env.d entry is just completely broken (and never got updated).
*** Bug 171013 has been marked as a duplicate of this bug. ***
*** Bug 122646 has been marked as a duplicate of this bug. ***
This is still broken. First of all, the upgrade process left two cruft files in env.d. One of these was populating /etc/profile.env with a bunch of incorrect environment variables (the version-jvm and compiler no longer on my systems). Secondly, java-config-2 re-creates one of these verion-1 artifacts (referred to above) -- the 20java file. This file has nothing correct in it. It adds an erroneous path segment to manpath, and it adds two non-existent nodes to the config-protect variable (the version-1 config dir in /etc, and an env.d node that doesn't exist. While this is all pretty much harmless, it should be cleaned up as part of finishing up the upgrade process correctly.
java-check-environment in java-config-wrapper-0.16 now instructs to remove /etc/env.d/20java, so FIXED
