Bug#227587: [PROPOSAL] Java library dependencies
Ben Burton wrote:
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.
For example most of the recent Jakarta libraries require Java 2 core
classes (accoding to their documentation) but as I've said they work
with Kaffe 1.1.3 when using tomcat4. I'm sure that they can also be
compiled with recent classpath versions so the dependencies will be
"kaffe | classpath | java2-runtime". When gcj also works someday we have
the situation that I like to avoid: You have to check every possible
Java core package in main for each library that you build. And then
there are new Kaffe versions every coupld of months so you spend a lot
of packaging time trying to build your package with different core classes.
I think we can assume that all libraries work with java2-runtime, at
least I have not seen one that requires java1-runtime and does not work
with "JDK 1.2 and above". The next problem is that java2-runtime means
"JDK 1.2 core classes and above" but there's no way to specify "JDK 1.4
core classes and above" which is needed in some cases, e.g.
libtomcat4-java. So a dependency on java2-runtime basically tells us
nothing.
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) ?
Right, but this not only has to de done for libtomcat4-java but also for
all its dependencies. If some of them were not violating the current
Java Policy by just depending on java-common, this change would affect
over 10 packages. And the same again when someone discovers tha tomcat4
works with SableVM and/or gcj.
Asking libraries to just depend on nothing at all will again not help
fix anyone's broken installations.
Right, but the library will not be of any use even if you have Java core
classes installed (e.g. classpath or libgcj4). You need some kind of JVM
to do anything with them. BTW, these two packages don't even provide
java1-runtime since some parts (AWT) are missing.
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.
I really meant to say "are supposed to work with any core classes at the
same JDK level". So at least we agree on this. :-)
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.
Yes, but the difference is that C libraries are statically linked
against libc6 (even a specific version) while JARs can use any other JAR
that provides e.g. java.lang.Object.
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.
I would currently not recommend using the Debian JARs in custom projects
since they might have reduced functionality so they can be in main, e.g.
a missing Swing GUI. I'm planning an automated script that compares
Debian JARs with upstream JARs so we at least know about these differences.
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
I disagree. An application packager is the only one who knows what
external libraries are required. For example, when your application uses
BSF (Bean Scripting Framework) you must know if you also need JavaScript
(rhino), Python (jython) or XSLT Stylesheets (libxalan2-java).
> 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.
You might also need additional (build) dependencies in case you are
using dynamically loaded plugins. I think you can consider the above
external libraries for BSF or everything for ant-optional.jar plugins -
so you have to exactly know what's required in your application.
And BTW, we don't have a lot of Java application packages in Debian,
probably around 10. On the other hand, we have well over 50 library
packages and I like to reduce the required time to maintain them. It
already takes a lot of time to migrate a single package to main,
Stefan
Reply to: