Consider: # eselect java-vm list Available Java Virtual Machines: grep: /usr/share/java-config-2/vm/blackdown-jdk-1.4.2: No such file or directory grep: /usr/share/java-config-2/vm/sun-jdk-1.5: No such file or directory grep: /usr/share/java-config-2/vm/sun-jdk-1.6: No such file or directory [1] blackdown-jdk-1.4.2 [2] emul-linux-x86-java-1.6 [3] icedtea-bin-6 [4] icedtea-bin-7 system-vm [5] sun-jdk-1.5 [6] sun-jdk-1.6 Entries 1, 5 and 6 were all properly unmerged using: # emerge -C {package-name} and therefore no longer exist on my systems. These entries simply appear to be left over artifacts. Other than the visual annoyance, there doesn't appear to be any method of removing them. I did try to unmerge "eselect-java" and re-emerge it in an effort to force regeneration of the list of availabel java machines but that was unsuccessful. The old entries remained. Note that I have multiple PCs with this issue.
That means you have orphaned symlinks in /usr/lib/jvm/. They should have been uninstalled together with the respective jvm. If you uninstall icedtea-bin-6 for instance, does it still leave a symlink behind as the others did probably long ago?
(In reply to comment #1) > That means you have orphaned symlinks in /usr/lib/jvm/. They should have > been uninstalled together with the respective jvm. > > If you uninstall icedtea-bin-6 for instance, does it still leave a symlink > behind as the others did probably long ago? With your question as a clue, I looked at: # ls -l /usr/lib/jvm total 0 lrwxrwxrwx 1 root root 27 Jul 6 2010 blackdown-jdk-1.4.2 -> /opt/blackdown-jdk-1.4.2.03 lrwxrwxrwx 1 root root 33 Apr 20 21:38 emul-linux-x86-java-1.6 -> /opt/emul-linux-x86-java-1.6.0.45 lrwxrwxrwx 1 root root 25 May 22 20:47 icedtea-bin-6 -> /opt/icedtea-bin-6.1.12.4 lrwxrwxrwx 1 root root 24 May 1 06:11 icedtea-bin-7 -> /opt/icedtea-bin-7.2.3.9 lrwxrwxrwx 1 root root 21 Jul 6 2010 sun-jdk-1.5 -> /opt/sun-jdk-1.5.0.21 lrwxrwxrwx 1 root root 21 Sep 2 2011 sun-jdk-1.6 -> /opt/sun-jdk-1.6.0.27 # ls -l /opt total 88 drwxr-xr-x 4 root root 4096 Nov 30 2011 Adobe drwxr-xr-x 2 root root 4096 Aug 25 2010 REALbasic2009r5 drwxr-xr-x 2 root root 4096 Apr 27 23:56 bin drwxr-xr-x 3 root root 4096 Nov 2 2009 blackdown-jdk-1.4.2.03 drwxr-xr-x 3 root root 4096 Oct 10 2009 emul-linux-x86-java-1.6.0.06 drwxr-xr-x 3 root root 4096 Jul 27 2010 emul-linux-x86-java-1.6.0.20 drwxr-xr-x 5 root root 4096 Apr 20 21:38 emul-linux-x86-java-1.6.0.45 drwxr-xr-x 3 root root 4096 Apr 5 2011 firefox drwxr-xr-x 7 root root 4096 May 22 20:47 icedtea-bin-6.1.12.4 drwxr-xr-x 7 root root 4096 May 1 06:11 icedtea-bin-7.2.3.9 drwxr-xr-x 5 root root 4096 May 22 20:47 icedtea-web-bin-6 drwxr-xr-x 5 root root 4096 Nov 25 2011 icedtea-web-bin-7 drwxr-xr-x 3 root root 4096 Jul 31 2011 icedtea6-bin-1.10.2 drwxr-xr-x 3 root root 4096 Aug 6 2010 icedtea6-bin-1.8.0 drwxr-xr-x 3 root root 4096 Jul 27 2010 netscape drwxr-xr-x 2 root root 4096 Jul 14 2012 rar drwxr-xr-x 4 root root 4096 Dec 1 2009 seamonkey drwxr-xr-x 4 root root 4096 May 2 2012 stuffit drwxr-xr-x 3 root root 4096 Oct 23 2009 sun-jdk-1.5.0.18 drwxr-xr-x 3 root root 4096 Aug 20 2011 sun-jdk-1.5.0.21 drwxr-xr-x 3 root root 4096 Jun 5 2009 sun-jdk-1.6.0.13 drwxr-xr-x 3 root root 4096 Jul 27 2010 sun-jdk-1.6.0.20 # du --max-depth=1 /opt 8 /opt/sun-jdk-1.5.0.21 126608 /opt/icedtea-bin-6.1.12.4 173644 /opt/Adobe 66244 /opt/icedtea-bin-7.2.3.9 332 /opt/seamonkey 8 /opt/icedtea6-bin-1.10.2 744 /opt/rar 8 /opt/blackdown-jdk-1.4.2.03 8 /opt/emul-linux-x86-java-1.6.0.06 8 /opt/REALbasic2009r5 8 /opt/sun-jdk-1.5.0.18 316 /opt/bin 123184 /opt/emul-linux-x86-java-1.6.0.45 16 /opt/firefox 8 /opt/sun-jdk-1.6.0.20 8 /opt/sun-jdk-1.6.0.13 888 /opt/icedtea-web-bin-6 8 /opt/icedtea6-bin-1.8.0 896 /opt/icedtea-web-bin-7 8 /opt/emul-linux-x86-java-1.6.0.20 184 /opt/netscape 5892 /opt/stuffit 499032 /opt As you can see, this system is at least 4 years old. Over time, I appear to have accumulated quite a few artifacts. As I see it, every /opt directory which has 8 blocks allocated should probably be removed. I'm assuming it's safe to manually remove both the orghaned symlinks as well as the essentially empty /opt/{java vm}. To my best memory of events, I've always properly (at the time) unmerged older vms as per various notices. As an enduser, I'm not sure how you want to or should handle this. Perhaps eselect-java can be made smart enough to issue a warning to the effect: "Artifacts left from previous unmerged java vms found. Do you want to remove these artifacts?" On the other hand, perhaps a new function can be added to eclean such as 'eclean-cruft' where empty directories in places like /opt exist and broken symlinks can be found and removed. As I am beginning to see it, this is more properly a cruft issue and might be better treated as such. If such a function is already available, I'd love to be clued in! Something to think about anyway. Back to my issue: If someone tells me it's safe to manually remove the broken symlinks and the empty /opt/{java-vm} directories, then you can close this bug/request or convert it into something that makes more sense to you. If someone wants to look at this more closely and would like me to test some kind of automated process, I can leave as is and test as needed. I do have layman installed and am comfortable with loading packages into /usr/local/portage/
BTW - I did uninstall icedtea-bin-6 and the related entry dissapeared. However, it was re-installed during an 'emerge @world'. I think this was because =virtual/jdk-1.6.0-r1 is still installed on these systems. I'm assuming I don't actually need =virtual/jdk-1.6.0-r1 anymore and can perform: emerge -C =virtual/jdk-1.6.0-r1.
You can manually delete those orphaned files. They should have been removed by Portage anyway. As you can no longer reproduce the issue with current Portage I presume the issue got fixed at some point or you did something to that directory manually before and Portage left those files for having been modified. Personally I think doing the cleanup / issuing a warning in java-check-environment instead of eselect java-vm would be preferable tho.
(In reply to Ralph Sennhauser from comment #4) > You can manually delete those orphaned files. They should have been removed > by Portage anyway. As you can no longer reproduce the issue with current > Portage I presume the issue got fixed at some point or you did something to > that directory manually before and Portage left those files for having been > modified. > > Personally I think doing the cleanup / issuing a warning in > java-check-environment instead of eselect java-vm would be preferable tho. I'm going to manually clean up the broken symlinks and remove all the empty directories. Of all the empty directories under /opt, only the REAL subdirectory had a manual change by me. That was to enter a temporary license. All the other empty directories should have been deleted by Portage. Your suggestion that warning/cleanup should be done at java-check-environment is a good one. I'm not a programmer so it won't be me volunteering for that effort. ;) In the meantime, if anyone else notices the same cruft and finds this report, they'll know to do a manual cleanup as well. Please feel free to either close this bug or re-purpose it to a request to add a clean up function where appropriate. Thank you for your help!
