Re: Policy change proposal, Re: Bug#176628: sablevm: package incorrctly provides java1-runtime
> 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.
Reply to: