Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Ben,
* Ben Burton wrote:
>Hi. I think there are some interesting ideas in this proposal, and
>there are also some ideas that are more concerning to me.
As you didn't critzise the getclasspath idea (as nonone else has), I
presume, that this is good for the nxt proposal. Same for the
browser-plugin?
>> 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.
The downside of this is, that we will have another+ year until java
works better than now. A lot of FAQs about mozilla plugins and so on...
IMO, there are not so many java package to make this task impossible,
Mostly the changes would be some rewrite in the startscripts and in
debian/control. And most of the packages are still in contrib and
require manual handling (either by using equivs or BD sources)
>> 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>?
Sun names it Java2 Runtime Environment version 1.4. Actually I don't
mind... AFAIK, the java1 to java2 transition was the only time API was
cleaned up (although the swing API wasn't part of java then).
>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.
This can be done by two way: Either policy reqirering that a all
/usr/bin/java-* need to update their bootclasspath. Packages could
then depend on the new API package.
Or the package wrapper script simple adds the bootclasspath itself.
>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?
|- 10 points, if the alternative is spec complient, but actually a
| based on a higher spec (1.3 <-> 1.4)
>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?
IMO the 1.x should be enought. Ok, then we will get problems with new
API classes, but most of the x.x.x releases should be bugfixes.
We will never get this 100% right, without depending on a certain
version of a certain vendor. :(
>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.
Yes :( This could be stoped by dpkg handling versioned virtual packages.
OTH, it seems, that most of you problems go away, when we have this
virtual package only for ~100% compatible JRE (=unfree ones) and
handle kaffe and gcj independently. This will not be the best, but at
least it leaves a interface to the nonfree JREs, so that packages
could then depend on this interface and kaffe and gcj instead of a
infinitive number of places where java could be.
>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.
So let java-common contribute such a script.
>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)?
Then you should indicate this with JAVA_HOME. It shouldn't be a
problem to add a bin/java wrapper to gcj (it should be a one liner,
judging by the way it was working in the RedHat eclipse Mailinglist)
>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.
Then we have to keep the java2-runtime virtual package and almost
every JVM will Provides: java2-runtime, java2-runtime-1.x
Having /usr/bin/java as a script, which chooses one of the provided
java-* is IMO clearer. Not everyone is able to change alternatives.
>> 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).
gij can be made to comply to this struckture. $JAVA_HOME has a big
advantage, that almost every script sets it itself and is then passed
on to the real starter script. Same thing for the ant.
>structure (which btw, is not mandated or even suggested by policy).
>Thus JVMs such as gij cannot be used.
True. Maybe we should?
>As an example, jython does not use a directory $JAVA_HOME, but simply a
>binary $JAVA (which defaults to /usr/bin/java). For example:
>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.
Thats why I added 'may honor' and 'does not need to make sanity checks
in this case". The reason for that paragraph was more that this
practise is made clearer and documented. tomcat4, ant, eclipse all
honor it, but nothing is saying it (man tomcat4 isn't even there...
Eclipse will say it in the next version <ooups...>).
[delete this para and seperate bins and libs]
>> |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.
>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.
If I'd say it makes sense for me, I'm lying (and would have to
introduce another package for eclipse...). But is much clearer to
depend on libjython<version> than 'jython'. There are a lot other
small packages, which have just one small script inside.
Anyway, IMO, this would mean, that if it is uses/can be used as
'libjython<version>', it should have its jars in /usr/share/java.
'Auxiliary classes' means (for me), things like the startup.jar of
eclipse or every plugin jar. Maybe I should reprase the whole to speak
of 'public jars' or 'library jars' which can be reused and 'private
jars', which can't.
>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.
This is the same as deleting i, isn't it?
>I hope I haven't deterred you by being overly critical;
The others were worse :)
>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.
ACK
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: