About java virtual dependencies and provides and the Java Policy
Hi,
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,
java6-runtime, java7-runtime
icedtea-java7-jdk provides: java-sdk, java2-sdk, java5-sdk, java6-sdk,
java7-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
some examples:
* groovy depends on java-gcj-compat | java-virtual-machine (not on any
runtime)
* 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 |
java-virtual-machine
* 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
with IcedTea7)
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...
Thanks, Eric
Reply to: