Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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 jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: