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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
