Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Ean,
No need to CC me.
* Ean Schuessler wrote:
>Your scheme is sound in theory, but isn't a solution for Java under the
>Debian OS. It means that virtually all Java packages in Debian would sit
>in contrib. That's just not acceptable.
Yes, I noticed that after writing my response :(
>Now that I am putting some real effort into Kaffe again I would like to
>see an actual functioning framework of Java applications in main.
>There is no Free VM that I am aware of that supports either Sun's 1.4 or
>1.3 or even 1.2. Your solution doesn't fulfill the Social Contract and
>not even Java is specially immune.
On the other hand there is this 'and our users' part in there. And
they expect, that when I install a JVM of a certain version, that all
programms, which require a JVM of that version will work.
>I do see your point about alternatives. If we constrain my suggestion to
>just base VM classes that problem goes away.
It will still be a real mess :( Just when you want to have 10 base
packages, it will be 10! of alternatives:
java-net
java-nio
java-awt
java-awt+net
java-awt+net+nio
...
Do you want to setup such a lot of alternatives? The only other
sollution I can thing of is Conflicts: java2-... and so effectivly
having just *one* JVM installed at a time. This would mean, that you
will probably end up in a situation, where two free VM have each a
package, which is needed and and which is not in the other VM. -> Mess
again...
>Base class libraries are
>not currently shared by any VMs I am aware of. Such an effort would be a
>worthy cause but it isn't likely to happen anytime soon.
But you could add other packages (-> Jars) to your bootclaspsath and
in this way get the same bootclasspath than the BD/SUN/IBM JVM.
>Instead of giving me a flat "that won't work" can you see a way to
>modify my approach? Is there some way that a classpath could be
>constructed from functional dependencies in a way that works for more
>than base classes?
IMO, it should work like this:
* Tomcat Depends: on java2-runtime-1.3|java2-runtime-1.4
* kaffe Depends: on Classpath, Xerces, ... and Provides:
java2-runtime-1.4
Also, it adds a wrapper script, which puts all this jars to the
-bootclasspath (if we switch to my JarDF sheme, this would be just a
simple "kaffe -bootclasspath `getclasspath -boot` $@") and set up a
alternative for /usr/bin/java-1.4
Another thing could be to add a further package/virtual package, which
indicates, that a nonfree JVM is needed. Packages could then Depend
on java2-runtime-1.4, unfree-runtime, and get one of the full featured
VMs, which would be by default have higher alternatives, that the not
100% compatible ones.
>Or is my criticism of your scheme unfounded?
It's not. But I can't see a better sollution for this problem :(
>From a users point of view, we should have a /usr/bin/java, which is
able to run everything, which the 'world outside' throws at it.
>From a DFSG and debian POV, we want to have as many packages in main
as possible. This means, that we have to put up a /usr/bin/java, which
isn't able to run everything, which is thrown at it.
IMO, our priority should be on the first. Debian does not gain
anything, if we have a setup, which will fail in some/most cases.
If we do that, we again end up in the same situation as now, where
everybody Depends on $JAVA_HOME/bin/java, where JAVA_HOME is searched
for by a ever again script snippet.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: