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
