About java virtual dependencies and provides and the Java Policy
browsing through the repositories to check some Java stuff, I find quite
some confusion around virtual packages:
icedtea-java7-jre provides: java-runtime, java2-runtime, java5-runtime,
icedtea-java7-jdk provides: java-sdk, java2-sdk, java5-sdk, java6-sdk,
(java5 and 6 add the headless combinations to those)
icepick depends: default-jre-headless | java2-runtime-headless, java-common
gij provides: java-runtime-headless, java-virtual-machine,
java1-runtime-headless, java2-runtime-headless, java5-runtime-headless
libgcj9-0-awt doesn't provide anything (not even javasomethingruntime)
default-jre-headless, default-jre, java-gcj-compat and
java-gcj-compat-headless are rather aligned with gij...
And I'm probably missing a few more interesting combinations...
At the same time, the Java Policy (as found in java-common) is still
only speaking about java-compiler, java2-compiler, java-virtual-machine,
java1-runtime and java2-runtime.
The library/program packagers depend on what they feel, just to take
* groovy depends on java-gcj-compat | java-virtual-machine (not on any
* libregexp-java depends on java-gcj-compat | java1-runtime |
java2-runtime (not on java-virtual-machine)
* freemind depends on j2re1.4 | java2-runtime, j2re1.4 |
* azureus depends on java-gcj-compat | java-virtual-machine,
java-gcj-compat | java2-runtime
So, bottom line, it's quite confusing for me as simple packager, and it
doesn't solve the requirement expressed a while ago to make the
difference between Sun's vs. free/classpath implementations of Java. And
perhaps the requirement is obsolete or incorrect since the apparition of
OpenJDK/IcedTea... (but I'm not convinced because FreeMind doesn't work
Wouldn't it be time to update the Java Policy with clear and consistent
instructions (and some examples), and give all Java packagers a chance
to properly update their package dependencies before the next Debian
release? Possibly with a round of bugs mass-filing...
My personal opinion is that the virtual packages should have 3 dimensions:
- jdk vs. runtime
- version 1, 2, 5, 6, 7...
- complete or not (i.e. (could) pass Java certification or not)
the virtual-machine vs. runtime thing doesn't seem really relevant to me...