Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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. :)
Reply to: