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