Bug#227587: [PROPOSAL] Java library dependencies

[Stefan Gybas <sgybas@debian.org>]

Package: java-common
Version: 0.22
Severity: wishlist

I propose to change the following paragraph in section 2.4. of the 
Debian Java policy

> Java libraries must depend on the needed runtime environment
> (java1-runtime and/or java2-runtime) but should not depend (only
> suggest) java-virtual-machine.

to:

Java library packages must depend on other library packages if they 
can't be used without them. If other libraries are only required by 
parts of the library, they should suggest the required library package 
instead.

Reasons:

1. Currently library packages are not required to depend on other
   libraries that they use. A dependency should not be used when only
   parts of a library require other libraries, for example as in
   ant-optional.jar. It's then up to the packager of a Java application
   to decide which other JARs are really required.

2. Dependencies on java*-runtime don't make a lot of sense:

   java*-runtime are both virtual packages and packages always
   should depend on "real_package | virtual_package" (so apt and others
   know what to do when they are first installed). Most Java libraries
   have a dependency like "classpath | java1-runtime | java2-runtime".
   This will keep them from migration to testing since the real package
   that provides java*-runtime might not be available for all
   architectures.

   It's almost impossible to determine if a library works with
   java1-runtime and/or java2-runtime. This can only be decided when
   you have an applications that uses the library. For example, tomcat4
   can now be run with Kaffe 1.1.3 so a lot of libtomcat4-java's
   dependencies actually work without a full "Java 2 runtime
   environment" although they depend on "java2-runtime".

3. Depending on java-common (IIRC this was mandated by a previos version
   of the Java Policy) is also not needed since there's nothing but
   documentation in java-common. This might change if we put some
   scripts to automatically generate a class path in java-common.

4. Libraries are supposed to work with any JVM so depending on
   known-to-work JVM packages is also not sensible: One library might
   depend on kaffe, another one on sablevm. An application which uses
   them both might work with Kaffe but dpkg would insist on installing
   SableVM even if it's not required.

To summarize: I'd like to move the task of determining the actual 
dependencies to the packagers of Java applications. They can test them 
with specific JVM packages and know which "optional" JARs are required 
to run the application.

Stefan