Hallo Per, No need to cc me each time.
* Per Bothner wrote: >You may have to do that. If you don't have a VM that has been >*tested* with the package you're trying to install, then you >don't know if you can satisfy the dependency. >For convenience, you can say (I don't know the appropriate syntax): >jdk version >= 1.2 | gcj version >= 3.3 | kaffe version >= ??? If this is the consensus, I will replace my Proposal by more tighter one. Tjis will mean, that you have a 'API' way to access JVM outside of the debian packageing system (basicly java2-runtime-1.4 and the alternative /usr/bin/java-1.4 for all unfree JRE 1.4 Javas). In the end, this ill mean, that we have Dependencies like this: java2-runtime-<version> | kaffe (>=1.1.1)| gcj (>=3.3.x) and startscripts, which do this: for i in /usr/bin/java-1.4 /usr/bin/kaffe /usr/bin/gcj ; do ... done Even if I'm not happy with this, it is at least a way to get the unpackaged JREs workig with our packages. I will still ask, that all 'java' alteratives (kaffe, gcj, etc) will add as much API to their bootclasspath as possible. >but that is no guarantee. A later version of JDK may add more >methods to an interface (Sun has been known to do this), and if Sun to an interface? >You can also "java-compatible-with-jdk1.3" but no Free JVM >are likely to satisfy such a constraint anytime soon. >(compilatible-with-jdk1.1 is getting close, though!) You mean because of swing? Anyway: what about the second part of my proposal: adding a well defined classpath to each package. 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]