[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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, 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: