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

Re: [Summery] Re: Integrating the FOSDEM 06 Draft into the Java

OK, I'm not exactly enthusiastic, but I can live with this, as long as the wording of the policy is adapted accordingly.

Why I'm not enthusiastic: should I manage to get into Debian yet another Java runtime, which is not compatible with either gcj, nor with openjdk, then the result could be that quite a lot of packages wouldn't be policy compliant anymore, because they wouldn't work with "all" JRE anymore. You might say that it's a constructed case, and it is, that's why I can live with this, but it means still for me that the policy isn't fully coherent.


Matthew Johnson wrote:
On Fri Mar 26 17:37, Eric Lavarde wrote:
They should build-depend on default-jdk and depend on default-jre | javaN-runtime
I have some problems with this:

1. the policy states something like "javaX-runtime fulfills the Java X specifications" (sorry, the patches are not reachable right now), but gcj/gij specifically does not fulfill the Java X specifications (else they wouldn't be incompatible with sun's Java resp. openjdk).

Well, that's not a useful definition for them in that case and should probably
be changed (in a future patch to policy)

2. On one side, in order to depend on default-j, programs and libraries must work both with openjdk and gcj, such programs/libraries should then depend on default-j, and only such programs/libraries can depend on javaX-runtime. The result is that javaX-runtime and default-jre are more or less interchangeable, and only confuse people (well, me at least).

No, default-jre is a concrete package pointing to specifically one JRE on a
given platform.  javaX-runtime is a virtual package provided by mane packages.
Depending on default-jre says "I must have the default for this platform".
Depending on default-jre | javaX-runtime says "I can work with any JRE, but if
you don't already have one, please give me the default".

3. gcj's versioning doesn't follow Java's versioning (X), so that each new version of gcj is just a more and more complete version of any X version of Java. Example: package MyJavaProgram depends on gcj-jre (>= 4.4) | javaX-runtime because it doesn't work with gcj 4.3. But user already has gcj-jre=4.3, which also provides javaX-runtime --> failure.

Then you want Conflicts: gcj-jre (<< 4.4)

4. On the other hand, openjdk and sun's java are really interchangeable and would justify a javaX-runtime, as their own versioning/naming follows the X schema.

Bottom-line, I would ask to either suppress javaX-runtime all together as being useless or even dangerous (as per point 3), or (my preferred) to reserve it for runtime environments which have passed the Java Compatibility Tests.

Personally now that we have openjdk I think we should drop Sun's JRE, at which
point you don't need a virtual package for them.

You _do_ need something for "Will work with whichever of openjdk/sun/gcj
happens to be installed", which is what javaX-runtime currently provides. The
versioning is mainly to ensure you have something which can read the classfile
version you compiled to.

Reply to: