Re: priorities for java alternatives
On Wed, May 24, 2006 at 08:29:43AM -0500, Tom Marble wrote:
> Eric Lavarde - Debian wrote:
> > Speaking of alternatives, it would be nice to have a mean to completely
> > switch from one Java alternative to another. Currently you need to modify
> > more than 10 different alternatives in order to switch from e.g. kaffe to
> > Sun's Java or back.
> > I don't know how this could be fixed, but this is cumbersome. Wouldn't it
> > be possible to define only alternatives for java and javac, and everything
> > else would be slave alternatives of the both, depending if they're meant
> > to be Runtime or Development commands?
>
> You are correct. A solution to this problem has been incorporated into
> java-common 0.25: update-java-alternatives(8)
>
> Each technology implementation defines the set of runtime, development
> and plugin alternatives in a file:
> /usr/lib/jvm/.$jname.jinfo
> Contents of /usr/lib/jvm/.java-1.5.0-sun.jinfo are shown below [1]
>
> This allows update-java-alternatives to switch the entire set of
> executables (and slaved man pages) to the desired implementation.
>
> An open issue (for which there is not yet a bug for java-common) is
> that we need to create a set of all possible alternatives
> (the union of all known .jinfo entries) in java-common so that
> update-java-alternatives can be modified to set the alternatives
> not available by a given implementation (i.e. the difference in
> of the sets [.all.jinfo - .$jname.jinfo]) to a noop implementation
> (and corresponding man page). In the case of executables this can
> simply be one shell script which says that the given command is
> not yet available for this implementation: $jname
>
> A second issue is update-java-alternatives needs to get an
> option like "update-alternatives --display" perhaps
> "update-java-alternatives --jname" which outputs the
> name of the currently chosen implementation.
>
> A third issue is that the test to see if update-java-alternatives
> is running as root should only be taken only if an action
> (and not just a query) is taken.
>
> As I am not (yet) a DD I cannot make these changes myself.
> More importantly does everyone agree with this approach?
Well, we need something like this. It was my mistake that I just
uploaded this when I got the prepared package from Matthias Klose.
We should have discussed this first. At last FOSDEM in Bruxelles we
discussed this a bit but got no real solution.
I think this approach is really good and will help our users. Some time
ago I startet to write a debconf frondend for a similar thing some time
ago. I will need to adjust it to this new mechanism and release it for
public review. My plan would be add this frontend to the java-common
package.
Cheers,
Michael
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Reply to: