> If I may make a proposal, as someone who's just a > lurker here, I'd say remove the 'provides > javax-runtime' tag from the free VM releases that > obviously lack the functionality of the tagged JDK > release, according to japitools. But only allow Java > programs to get into 'debain free' if they explicitely > name in their requirements a free VM as the default > choice and the maintainer has gone through the work of > testing it, and getting it to run with either kaffe, > gcj, sablevm, or some other free VM included in > 'debian-free'.
Basically my argument is going to be this: for major unsupported components (e.g., awt and swing) we introduce new virtual packages, as discussed earlier. For minor unsupported quibbles, we file bugs against JVMs. I'd *much* rather this than simply removing the virtual packages altogether from a JVM that doesn't fully support the java specs. Virtual packages by definition have unclear levels of 'true support'. For instance, how many packages that provide www-browser can in fact correctly view your average online banking site? But certainly for simple things like www.debian.org, they all function just fine. I see java-runtime as a similar situation. I take a simple Java app that will run on any JVM that is reasonably complete, and I want to just have Depends: java1-runtime, allowing the user to download whatever JVM they see fit. I don't want to have to keep track of the multitude of JVMs available in debian and keep the Depends: line updated as they all shift and change. Of course there are more complex packages that require components that are often poorly supported in free JVMs. Such as AWT, or java2 classes that aren't present in JDK 1.1. Hence the java2-runtime and (proposed) java-awt-runtime (or whatever) virtual packages. For incompatibilities that aren't covered by virtual packages as described above, it seems far easier to ask the single JVM maintainer / developer to fix the bug than to ask every maintainer for every java app or library to continually test their package against every release of every JVM to make sure their Depends: line remains up-to-date. As an aside, it's also worth noting that even if package dependencies become so restricted that they end up depending on a single JVM, having a package depend on a specific JVM doesn't at all imply that that specific JVM will be called when your startup script runs /usr/bin/java, and hardcoding a specific JVM in your startup script removes the whole point of being able to choose between different free and non-free JVMs. For this problem I again point to the JVM registry that I've mailed about several times on this list (and even wrote an initial implementation for), that people have said looks nice and then that has been summarily ignored. :) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
