> > Thus the *absence* of java2-runtime in the depends list is
> > an indication that the package should work on most JVMs in
> > debian.  I would however expect these packages to run under
> > java2 as well.
> 
> In my understanding the absence of java2-runtime means that a package 
> that (solely) provides java2-runtime can't be used.

*sigh*.. what we were arguing was that the use of java1/2-runtime
conveys non-trivial information.  If you still disbelieve this, let me
make it clear for you:

If package A depends on java1-runtime only, package B depends on
(java1-runtime | java2-runtime) and package C depends on java2-runtime only,
it is quite clear that C will need java2-specific stuff whereas A and B
will not.  Most JVMs in debian provide most of the java1 API,
whereas support for java2 is somewhat less complete.

Sure, this is all a very loose specification.  But as I've said before,
you do nothing to improve this (in fact you just ignore API dependencies
altogether).  See Jan's proposal for how this might be tightened up.

> Ok, this seems to be another misunderstanding: I want Java libraries to 
> depend on all APIs except for the core APIs. I simply assume that 
> libraries work with any JVM/JRE, although this might not be correct.

No - if a library uses a class that is not available at runtime, the JVM
can crash (class not found).  You can get around this but it requires
some careful library design including the use of introspection, etc
(jython uses these techniques).

> Library packages never depended on a JVM (virtual package 
> java-virtual-machine), just the core classes. The definition of 
> java*-runtime means just the core classes, no JVM.

Pardon me, "JVM" was easier to type than "package providing a set of
core classes", and I used it as shorthand since most (all?) JVMs in
debian provide their own core classes anyway.  I figured it was clear
what I meant.  Feel free to replace "JVM" with "package providing a set
of core classes" in all my mails on this subject - they were written
with this shorthand in mind.

Ben.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to