Bug#227587: [PROPOSAL] Java library dependencies
Hi. Further on this proposal:
> Java libraries must depend on the needed runtime environment
> (java1-runtime and/or java2-runtime) ...
I do not like deleting this requirement. Although there are some
serious problems with it (such as different libraries working to
different degrees on different JVMs), removing this dependency will
not solve these problems - it will in fact give the user *less*
information regarding what they require. These java1-runtime and
java2-runtime dependencies do at least tell you whether a library
requires java2 core classes or not.
> It's almost impossible to determine if a library works with
> java1-runtime and/or java2-runtime.
It at least as feasible as determining whether an application works with
java1-runtime and/or java2-runtime. Certainly it should be clear which
classes are used by the library (try compiling it against different java
APIs).
> 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".
This is because java2-runtime and java1-runtime are very loosely
specified dependencies. Removing them will not help fix anyone's
broken java installations. If tomcat4 needs java2 in most cases
but works with kaffe regardless, why not just add kaffe as an optional
substitute for java2-runtime in this case, i.e., have tomcat4 depend
on (kaffe | java2-runtime) ?
> 3. Depending on java-common (IIRC this was mandated by a previos version
> of the Java Policy) is also not needed
Agreed. Note however that it was never required by libraries in the
first place. IIRC it's only required for JVMs. Sure, the libraries
require JVMs but so do applications. If you want to make java-common
optional, you should amend the "JVMs require java-common" clause, not
delete an essentially unrelated dependency (libraries require a JVM).
> 4. Libraries are supposed to work with any JVM so depending on
> known-to-work JVM packages is also not sensible:
Asking libraries to just depend on nothing at all will again not help
fix anyone's broken installations.
Note the difference between JVMs and java core classes. Libraries are
supposed to work with any JVM, but they still require a particular version
of the core Java API, which is what the java1-runtime and java2-runtime
dependencies attempt to describe.
IMHO, removing the "libraries require core Java classes" dependency is
like removing libc6 from the dependencies of a C library. Quite clearly
the libraries will use core Java classes, so I would argue this
relationship should be made explicit.
> To summarize: I'd like to move the task of determining the actual
> dependencies to the packagers of Java applications.
I'd argue this is definitely the wrong approach:
1) Libraries are not just for use by other debian apps. People use
them in their own custom software as well. In this case, the only
place they're going to get the right dependencies is from the library
package itself.
2) As an application packager, you know what libraries your app uses.
You shouldn't have to know the external libraries in intimiate detail as
well - in particular you shouldn't have to chase down what classes are
used by the libraries but not by your app itself. An example here is
KDE packaging - you generally build-depend on kdelibs4-dev, but you rely
on the fact that the kdelibs maintainers have tracked down the multitude
of other libraries that kdelibs uses for itself that will also need
to be installed.
Ben.
Reply to: