Hi, I've just updated the JRE to 1.4.2.6 from SUN's website. The RPM provided by SUN installed it in /usr/java. I thought this was the wrong place so i did a "whereis" and tracked the current version down to "symlinks" in the /etc/alternatives directory. They all point to java programs etc in /usr/lib/jvm/jre-1.4.2-sun. Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it. regards Ian
ianseeks wrote:
Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it.
I think # rm /usr/lib/java # ln -s /usr/lib/java /usr/java/jdk1.4.6 ought to do it (check the directories for SuSE 9.2 and if you've only downloaded the JRE). You may also want to change the links in /opt/MozillaFirefox/lib/plugins and /opt/mozilla/lib/plugins since the recent security issue in java affects the browser plugin. If you're not dependent on a particular version of java and aren't developing applications that you want to be sure will run on java 2 1.4.x, why not use 1.5.0? IMHO it looks nicer, and it supports generics. The biggest hassle I've had is that XEmacs always quizzes me about 1.5.0 before compiling. -- JDL
John, Ian, On Monday 10 January 2005 00:25, John Lamb wrote:
ianseeks wrote:
Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it.
I think
# rm /usr/lib/java # ln -s /usr/lib/java /usr/java/jdk1.4.6
The arguments on the "ln -s" invocation are backward.
ought to do it (check the directories for SuSE 9.2 and if you've only downloaded the JRE).
...
-- JDL
Randall Schulz
Randall R Schulz wrote:
John, Ian,
On Monday 10 January 2005 00:25, John Lamb wrote:
ianseeks wrote:
Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it.
I think
# rm /usr/lib/java # ln -s /usr/lib/java /usr/java/jdk1.4.6
The arguments on the "ln -s" invocation are backward.
No, it's not! You just "copy" the existing entry to the new location, which then is the symbolic link instead of a regular file, directory or whatever! Therefore it follows the usual methods.
ought to do it (check the directories for SuSE 9.2 and if you've only downloaded the JRE).
...
-- JDL
Randall Schulz
Yours Martin
Martin, On Monday 10 January 2005 08:37, Martin Deppe wrote:
Randall R Schulz wrote:
John, Ian,
On Monday 10 January 2005 00:25, John Lamb wrote:
ianseeks wrote:
Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it.
I think
# rm /usr/lib/java # ln -s /usr/lib/java /usr/java/jdk1.4.6
The arguments on the "ln -s" invocation are backward.
No, it's not! You just "copy" the existing entry to the new location, which then is the symbolic link instead of a regular file, directory or whatever! Therefore it follows the usual methods.
Yes, they are backward. Your invocation creates a symlink called "java" in the directory "/usr/java/jdk1.4.6" which points to the non-existent file system entity "/usr/lib/java".
Martin
Randall Schulz
Randall R Schulz wrote:
Martin,
On Monday 10 January 2005 08:37, Martin Deppe wrote:
Randall R Schulz wrote:
John, Ian,
On Monday 10 January 2005 00:25, John Lamb wrote:
ianseeks wrote:
Apart from manually re-creating all those links, is there a quick way to do it? And should I bother? I've updated opera to point to the new version in /usr/java and opera seems to be ok with it.
I think
# rm /usr/lib/java # ln -s /usr/lib/java /usr/java/jdk1.4.6
The arguments on the "ln -s" invocation are backward.
No, it's not! You just "copy" the existing entry to the new location, which then is the symbolic link instead of a regular file, directory or whatever! Therefore it follows the usual methods.
Yes, they are backward. Your invocation creates a symlink called "java" in the directory "/usr/java/jdk1.4.6" which points to the non-existent file system entity "/usr/lib/java".
That's the interesting point with it, the <source> doesn't need to exist.
Martin
Randall Schulz
Martin
Martin, On Monday 10 January 2005 11:04, Martin Deppe wrote:
...
Yes, they are backward. Your invocation creates a symlink called "java" in the directory "/usr/java/jdk1.4.6" which points to the non-existent file system entity "/usr/lib/java".
That's the interesting point with it, the <source> doesn't need to exist.
Yes, but a symlink that points to nothing is useless. Here's an example (now a bit out-of-date as far as versions go) of a proper orientation of the symbolic link you're trying to construct that illustrates my system's set-up: % ll /usr/lib/java lrwxrwxrwx 1 root root 12 2004-06-17 23:55 /usr/lib/java -> SunJava2-1.4/ And to clarify further: % ln --help Usage: ln [OPTION]... TARGET [LINK_NAME] ... The command that would create the symlink required for Java on my system (running 1.4.2) is: # rm /usr/lib/java # ln -s /usr/lib/SunJava2-1.4 /usr/lib/java
Martin
Randall Schulz
I've downloaded and installed Java 2 as suggested and it also went into /usr/java directory. It was an interesting thread regarding "ln" but unfortunately I wanted to know about "/etc/alternatives" and how to change all those links without a long winded manual approach. /usr/lib/java doesn't seem to exist anymore. It appears to be replaced by the "/etc/alternatives" idea. (See directory list below). "/usr/bin/java" is now a symlink to "/etc/alternatives/java" which in turn is a symlink to "/usr/lib/jvm/jre-1.4.2-sun/bin/java". I want to change this to /usr/java/jre1.5.0_01/bin/java ... and so on. I guess i'm going to have to work this out manually unless i can find a script that does this automatically. regards Ian drwxr-xr-x 2 root root 960 2004-12-27 09:51 . drwxr-xr-x 72 root root 6640 2005-01-10 19:36 .. lrwxrwxrwx 1 root root 35 2004-12-27 09:51 java -> /usr/lib/jvm/jre-1.4.2-sun/bin/java lrwxrwxrwx 1 root root 44 2004-12-27 09:51 java.1.gz -> /usr/share/man/man1/java-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 33 2004-12-27 09:51 javaws -> /usr/lib/jvm/jre-1.4.2-sun/javaws lrwxrwxrwx 1 root root 46 2004-12-27 09:51 javaws.1.gz -> /usr/share/man/man1/javaws-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 64 2004-12-27 09:51 jce_1.4.2_sun_local_policy -> /usr/lib/jvm-private/java-1.4.2-sun/jce/vanilla/local_policy.jar lrwxrwxrwx 1 root root 68 2004-12-27 09:51 jce_1.4.2_sun_us_export_policy -> /usr/lib/jvm-private/java-1.4.2-sun/jce/vanilla/US_export_policy.jar lrwxrwxrwx 1 root root 26 2004-12-27 09:51 jre -> /usr/lib/jvm/jre-1.4.2-sun lrwxrwxrwx 1 root root 26 2004-12-27 09:51 jre_1.4.2 -> /usr/lib/jvm/jre-1.4.2-sun lrwxrwxrwx 1 root root 34 2004-12-27 09:51 jre_1.4.2_exports -> /usr/lib/jvm-exports/jre-1.4.2-sun lrwxrwxrwx 1 root root 34 2004-12-27 09:51 jre_exports -> /usr/lib/jvm-exports/jre-1.4.2-sun lrwxrwxrwx 1 root root 26 2004-12-27 09:51 jre_sun -> /usr/lib/jvm/jre-1.4.2-sun lrwxrwxrwx 1 root root 34 2004-12-27 09:51 jre_sun_exports -> /usr/lib/jvm-exports/jre-1.4.2-sun lrwxrwxrwx 1 root root 38 2004-12-27 09:51 keytool -> /usr/lib/jvm/jre-1.4.2-sun/bin/keytool lrwxrwxrwx 1 root root 47 2004-12-27 09:51 keytool.1.gz -> /usr/share/man/man1/keytool-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 45 2004-12-27 09:51 kinit.1.gz -> /usr/share/man/man1/kinit-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 45 2004-12-27 09:51 klist.1.gz -> /usr/share/man/man1/klist-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 44 2004-12-27 09:51 ktab.1.gz -> /usr/share/man/man1/ktab-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 35 2004-12-27 09:51 orbd -> /usr/lib/jvm/jre-1.4.2-sun/bin/orbd lrwxrwxrwx 1 root root 44 2004-12-27 09:51 orbd.1.gz -> /usr/share/man/man1/orbd-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 41 2004-12-27 09:51 policytool -> /usr/lib/jvm/jre-1.4.2-sun/bin/policytool lrwxrwxrwx 1 root root 50 2004-12-27 09:51 policytool.1.gz -> /usr/share/man/man1/policytool-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 35 2004-12-27 09:51 rmid -> /usr/lib/jvm/jre-1.4.2-sun/bin/rmid lrwxrwxrwx 1 root root 44 2004-12-27 09:51 rmid.1.gz -> /usr/share/man/man1/rmid-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 42 2004-12-27 09:51 rmiregistry -> /usr/lib/jvm/jre-1.4.2-sun/bin/rmiregistry lrwxrwxrwx 1 root root 51 2004-12-27 09:51 rmiregistry.1.gz -> /usr/share/man/man1/rmiregistry-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 41 2004-12-27 09:51 servertool -> /usr/lib/jvm/jre-1.4.2-sun/bin/servertool lrwxrwxrwx 1 root root 50 2004-12-27 09:51 servertool.1.gz -> /usr/share/man/man1/servertool-java-1.4.2-sun.1.gz lrwxrwxrwx 1 root root 40 2004-12-27 09:51 tnameserv -> /usr/lib/jvm/jre-1.4.2-sun/bin/tnameserv lrwxrwxrwx 1 root root 49 2004-12-27 09:51 tnameserv.1.gz -> /usr/share/man/man1/tnameserv-java-1.4.2-sun.1.gz On Monday 10 Jan 2005 19:27, Randall R Schulz wrote:
Martin,
On Monday 10 January 2005 11:04, Martin Deppe wrote:
...
Yes, they are backward. Your invocation creates a symlink called "java" in the directory "/usr/java/jdk1.4.6" which points to the non-existent file system entity "/usr/lib/java".
That's the interesting point with it, the <source> doesn't need to exist.
Yes, but a symlink that points to nothing is useless.
Here's an example (now a bit out-of-date as far as versions go) of a proper orientation of the symbolic link you're trying to construct that illustrates my system's set-up:
% ll /usr/lib/java lrwxrwxrwx 1 root root 12 2004-06-17 23:55 /usr/lib/java -> SunJava2-1.4/
And to clarify further:
% ln --help Usage: ln [OPTION]... TARGET [LINK_NAME] ...
The command that would create the symlink required for Java on my system (running 1.4.2) is:
# rm /usr/lib/java # ln -s /usr/lib/SunJava2-1.4 /usr/lib/java
Martin
Randall Schulz
Ian, On Monday 10 January 2005 14:51, ianseeks wrote:
I've downloaded and installed Java 2 as suggested and it also went into /usr/java directory. It was an interesting thread regarding "ln" but unfortunately I wanted to know about "/etc/alternatives" and how to change all those links without a long winded manual approach.
Perhaps you could use "update-alternatives". "man update-alternatives" for details, of course.
/usr/lib/java doesn't seem to exist anymore. It appears to be replaced by the "/etc/alternatives" idea. (See directory list below). "/usr/bin/java" is now a symlink to "/etc/alternatives/java" which in turn is a symlink to "/usr/lib/jvm/jre-1.4.2-sun/bin/java". I want to change this to /usr/java/jre1.5.0_01/bin/java ... and so on. I guess i'm going to have to work this out manually unless i can find a script that does this automatically.
See above. I think it's meant to do just what you want.
regards
Ian
Randall Schulz
Aha.. now that sounds like a place to look. Thanks for that, i didn't realise those existed. Thanks to all for you comments and suggestions. Case Closed until the next time :o) regards Ian On Monday 10 Jan 2005 23:14, Randall R Schulz wrote:
Ian,
On Monday 10 January 2005 14:51, ianseeks wrote:
I've downloaded and installed Java 2 as suggested and it also went into /usr/java directory. It was an interesting thread regarding "ln" but unfortunately I wanted to know about "/etc/alternatives" and how to change all those links without a long winded manual approach.
Perhaps you could use "update-alternatives". "man update-alternatives" for details, of course.
/usr/lib/java doesn't seem to exist anymore. It appears to be replaced by the "/etc/alternatives" idea. (See directory list below). "/usr/bin/java" is now a symlink to "/etc/alternatives/java" which in turn is a symlink to "/usr/lib/jvm/jre-1.4.2-sun/bin/java". I want to change this to /usr/java/jre1.5.0_01/bin/java ... and so on. I guess i'm going to have to work this out manually unless i can find a script that does this automatically.
See above. I think it's meant to do just what you want.
regards
Ian
Randall Schulz
Hey Group; Since you brought up the /etc/alternative directory and all of it links. Why the heck is it even needed? I see no good reason even to have one link to another link back the the real binary just kind of a waste . Something like /usr/bin/file > /etc/alternatives/file > /usr/bin/file123 Why not /usr/bin/file > /usr/bin/file123 Sure file123 might be hard to remember so /usr/bin/file would be in your $PATH and solve the memory problem.
Yes, they are backward. Your invocation creates a symlink called "java" in the directory "/usr/java/jdk1.4.6" which points to the non-existent file system entity "/usr/lib/java".
That's the interesting point with it, the <source> doesn't need to exist.
Yes, but a symlink that points to nothing is useless. And a link to a link is also a waste
-- 73 de Donn Washburn " http://www.hal-pc.org/~n5xwb " Ham Callsign N5XWB 307 Savoy St. Sugar Land, TX 77478 LL# 1.281.242.3256 Dump Microsoft Software - Stop virus email Email: n5xwb@hal-pc.org " http://counter.li.org " #279316
Donn, On Monday 10 January 2005 17:21, Donn Washburn wrote:
Hey Group;
Since you brought up the /etc/alternative directory and all of it links. Why the heck is it even needed? I see no good reason even to have one link to another link back the the real binary just kind of a waste .
Not having looked into the stated rationales of the alternatives mechanism, I can only imagine that it's meant to systematize a solution to the need some users have (I know I sometimes do) to have multiple versions of a given piece of software installed and to be able to readily switch off between them.
...
Yes, but a symlink that points to nothing is useless.
And a link to a link is also a waste
Perhaps not as much as you think. The kernel caches symlink resolutions.
Donn Washburn
Randall Schulz
Randall R Schulz wrote:
Donn,
On Monday 10 January 2005 17:21, Donn Washburn wrote:
Hey Group;
Since you brought up the /etc/alternative directory and all of it links. Why the heck is it even needed? I see no good reason even to have one link to another link back the the real binary just kind of a waste .
Not having looked into the stated rationales of the alternatives mechanism, I can only imagine that it's meant to systematize a solution to the need some users have (I know I sometimes do) to have multiple versions of a given piece of software installed and to be able to readily switch off between them.
Very true that the /etc/alternative directory is a collection of links. However, what is wrong with removing one link and then relinking. Why do you need double links? Shades of Debian, Knoppix and Mandrake I need to fix this .signature file. It was lost recently during a reload So I went out on the net and found it - copy /paste and what you see is it. -- 73 de Donn Washburn __" http://www.hal-pc.org/~n5xwb " Ham Callsign N5XWB / / __ __ __ __ __ __ __ 307 Savoy St. / /__ / / / \/ / / /_/ / \ \/ / Sugar Land, TX 77478 /_____/ /_/ /_/\__/ /_____/ /_/\_\ LL# 1.281.242.3256 Dump Microsoft Software - Stop virus email Email: n5xwb@hal-pc.org " http://counter.li.org " #279316
On Mon, Jan 10, 2005 at 08:29:25PM -0600, Donn Washburn wrote:
Very true that the /etc/alternative directory is a collection of links. However, what is wrong with removing one link and then relinking. Why do you need double links? Shades of Debian, Knoppix and Mandrake
The explanation is in update-alternatives(8) man page: This is done so that the system administrator's changes can be confined within the /etc directory: the FHS (q.v.) gives reasons why this is a Good Thing. -Kastus
participants (6)
-
Donn Washburn -
ianseeks -
John Lamb -
Kastus -
Martin Deppe -
Randall R Schulz