Hi. I think there are some interesting ideas in this proposal, and there are also some ideas that are more concerning to me.
> It would be nice, if this, and the transition (if it should > happen...), are over before sarge is released. Given that we are this close to freeze, I would be *very* reluctant to push through such major changes in Java policy before sarge is released. We don't know how long the transition will take, and nor do we know what problems may arise as a result of the new policy. I would much prefer to release sarge and *then* look at tearing Java policy apart when we have the luxury of time to deal with whatever might go wrong. > Java Runtime Environments, which are complient to the Java Spec of a > specific Version, have to provide the virtual package > 'java2-runtime-<spec-version> and setup alternatives for > /usr/bin/java-<spec-version> and the corresponding manpage. I presume this is java-runtime-<spec-version>, not java2-runtime-<spec-version>? My biggest problem with this is that a JVM will frequently provide a range of APIs (e.g., all APIs <= 1.4). Similarly, a package will generally require any JVM implementing API >= version, not just == version. So say I have on my system a JVM that provides API 1.4 and a package that requires API 1.1. Does the package call /usr/bin/java-1.1 and depend on java-runtime-1.1? And if so, does my 1.4 JVM also provide these virtual packages and alternatives, or am I forced to download an older JVM that implements the 1.1 API but no higher? What will happen is either: - JVMs will have to provide virtual packages and alternatives for a range of APIs, not just one single API, or: - Packages will have to depend on an infinite variety of APIs and then have startup scripts that try an infinite variety of /usr/bin/java-xxx binaries. Since packages cannot have infinitely many dependencies, the only sensible solution is the first. But then, as a JVM providing API 1.4, do I just provide 1.0, 1.1, 1.2, 1.3 and 1.4? What about 1.1.1? 1.1.2? It seems we will need a clearer policy on how to handle this issue. Furthermore, it seems that virtual packages will slowly get more out of hand as the available APIs increase. > /usr/bin/java will be contributed by a package java2-runtime, which > depends on any of the java2-runtime-<spec-version> and will be kept > for backward compatibility. I don't think /usr/bin/java is simply an issue of backward compatibility. I want to have a working "java" binary on my path, just like I have a working "cc". Java is also called by people running their own apps, not just by debian package startup scripts. Since this /usr/bin/java depends on any of the runtime packages and since it is not provided as an alternative by these packages, I presume it will do something like scan through the available java-xxx binaries and choose the largest? What if I don't want to run the largest by default (e.g., I have blackdown java installed but I want to use the DFSG-free gij-wrapper as my default JVM)? It does seem that the alternatives system is well suited to dealing with /usr/bin/java, and I'd be happy for JVMs to provide /usr/bin/java as an alternative as well as /usr/bin/java-xxx. > Programms may honor the user set JAVA_HOME environment variable, > while looking for a java binary. If so, this should be clearly > stated in the manpage and other places, if possible. The programm > does not need to make sanity checks in this case. I'm not particularly happy with the idea of incorporating $JAVA_HOME into policy. One strong reason is the fact that some JVMs don't adhere to the $JAVA_HOME structure at all (notably gij). I'd like to just be able to specify a JVM binary, which should allow me to use any of the available JVMs. If I have to specify a $JAVA_HOME, I need a JVM that comes with a specially formed directory structure (which btw, is not mandated or even suggested by policy). Thus JVMs such as gij cannot be used. As an example, jython does not use a directory $JAVA_HOME, but simply a binary $JAVA (which defaults to /usr/bin/java). For example: JAVA=gij-wrapper jython JAVA=kaffe jython I'm not saying here that we should add $JAVA to policy. I'm simply saying I don't want to add $JAVA_HOME to policy. > Most of "2.3 Java Programms" will need to be replace by a updated > version (virtual package names). The part > |If they have their own auxiliary classes, they must be in a jar > |file in /usr/share/java. The name of the jar should folow the same > |naming conventions as for libraries. > should IMO be deleted: /usr/share/java will sometime be crouded and > in case of eclipse, it expects its internal jar files in specific > places, so I would need to make symlinks for no use. If the jar file > is interesting to be reused in other packages, it should be made a > separate package anyway (like just done with libant1.5-java). I don't think this is always the correct decision. Take jython for an example. Pretty much everything is in /usr/share/java/jython.jar, and this jar can be used as a library by other applications that want inbuilt scripting. To use jython as a standalone program, we add a single small script /usr/bin/jython. It makes no sense to me to split the jython package into two packages, one containing this single /usr/bin/jython script and one containing everything else. To resolve the issue you describe, I think a better solution is simply to replace the "must" with a "may" in the /usr/share/java paragraph. > Thanks for going through this :) I hope I haven't deterred you by being overly critical; you do identify some serious problems and I do like some of your ideas. Because of the loosely organised nature of Java libraries and the massive variety of APIs and structures of different JVMs, these problems are difficult to solve. Which is presumably why Java on debian is still in the loosely organised state in which it is. Ben. :)
