Re: Use of update-alternatives or JAVA_HOME
Hallo Matt,
Reply to the list, as I suspect, that you just missed the right key :)
At least I haven't found anything private in this mail
* Matt Zimmerman wrote:
>On Mon, Aug 11, 2003 at 10:58:18PM +0200, Jan Schulz wrote:
>> * Matt Zimmerman wrote:
>> >This is what update-alternatives does.
>> The problem is, that you can't tell it, that a program depends on a
>> java1.4.
>Of course you can. You just create a new alternative called java1.4, and
>only JREs which can provide that capability register themselves as
>alternatives for it.
That would be fine. Problem is, that you would have more problems with
it, because most programms are fine with /path/to/java, but not with
/usr/bin/java-1.4.
To name one: eclipse can use gcj as a target VM to run code in, with
just a small wrapper script of two lines, which is installed as
/something/java (patch seen on the RH eclipse ML, though).
>> To put it diferently: how would you find it, if /usr/bin/perl wouldn't
>> be the full featured perl, but a different and still incomplete perl
>> implementation.
Another good example it the use of
#!/bin/sh
and
#!/bin/bash
and then using bashism in the script.
Most of the time it will work, but then you will get a bug assigned to
you (guess why I just thought of this...), if anybody doesn't have sh
linked to bash.
>> I find u-a quite practical and I use it for the swt-java library. But
>> I'm using it with versioned names (libswt2.1-java), which are
>> interchangeable, and this should also apply to /usr/bin/java ->
>> /usr/bin/java-1.4
>Exactly.
If thats working for most packages and reasonable work for any other
package, then this is a nice sollution.
It would need some docs to make up some rules, how this alternatives
should be handled and what java version should provide which
alternative with what priority. It also needs new virtual packages.
associated with the u-a links.
java2-compiler{1.3|1.4|1.5}
java2-runtime{1.3|...}
java2-api{..} -> to be used with CLASSPATH and gcj/kaffe which will
use the same libs sometime in the future?
java2-browser-plugin{1.3|1.4{|c102}}
I would also suggest, that then the old java-virtual-maschine is then
depricated, together with the java-runtime|compiler (with and without
the '2').
If someone finds this usefull, I can write a proposel for this to be
included in the debian java policy. This won't be until end of august,
though, I will go on holidays on friday...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: