Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Ean,
* Ean Schuessler wrote:
>be. Some of NIO might be available but 1.4 security contexts may be
>non-existant. Therefore, I imagine something more like:
>Kaffe 1.1.1
>provides:
> java.awt1.1
[...]
I see what you mean, but this will simple not work: How do you want to
use alternatives?
My system lets you use the right /usr/bin/java-* and Depend: on this
version. Your Idea would mean, that we need
/usr/bin/java-awt+swing+nio+... Also, If I install tomcat, I simple
drom some webapps in there and I don't bother to check, whether awt is
there or not. Its a JVM and if tomcat runs on it, is should be 1.3 and
so it *has to* be there.
Thats why I also added the '-30 if the package is not 100% SUN java
compatible'.
This whole will mean, that some (free) JVM will probably not be ready
to 'Provide: java2-runtime-*', if some API can't be added by means of
Depedending on other packages or is just too buggy/beta.
The only alternative, I can think of would be to provide a really
empty classpath to all JVM and each programm has to add every single
jar, even java.* and the newly introduced xml/... API (which would
then need to be seperated into different packages), to the
bootclasspath. I don't think we can do that, esepccially, if you want
to use java outside of the package management system (java HelloWorld
wouldn't work).
java-1.4 means, that everything, what SUN calls java-1.4 is there.
>From the point of a user: if I have a 1.4 VM, I expect AWT being on
the classpath. If not, it's not java-1.4. So, if Kaffe can't get it's
bootclasspath together (by Depending on other packages and adding them
by means of a wrapper), so that it is acceptable to call it
/usr/bin/java-1.4 for for example tomcat, I don't think it should
provide this new virtual package. I prefer a free VM, but much more I
prefer a *working* VM.
Jan
Reply to: