Bug#227587: [PROPOSAL] Java library dependencies
Jan Schulz wrote:
* j2/1-runtime does not garantee anything *at runtime*, so it is
Right. That's exaclty the reason why I'd like to see them removed for
library packages. But I guess I have already told this... :)
useless in that respect. IMO, and that was the result of the policy
discusion [1], it should be replace by individual dependecies on
each 'known working' JVM package and then used by a 'for java in
<list>' code (which hopefully will be replace by a findjava script)
I think you are making the same mistake as Ben here: java*-runtime just
means the core classes, no JVM! If you need both, you need to depend on
"some_jvm_package | java-virtual-machine, some_rt_package |
javaX-runtime". In most cases a JVM also provides javaX-runtime so you
can use the same JVM package for some_jvm_package and some_rt_package.
See e.g. the ant and tomcat4 packages for examples.
This requirement is even more flawed, as the only thing, which is
garanteed, but unfortunatelly by *both* virtual packages, is
/usr/bin/java. You should know the result with using that
alternative...
Wrong. This is guaranteed by java-virtual-machine, not java*-runtime!
* There is currently no way to enforce (as with dpkg [3] or any script[2])
library package dependecies 'upwards' (lib needs JVM_A and will not
work with JVM_B. App chooses JVM_B), so IMO, the only thing what such
dependencies add are information for the application packager, what
JVM needs to be removed from the '<list>'. Which would be much
better in a README...
I don't want to put the burdon of testing all possible runtimes to
library packagers. In most cases they can't do this even if some unit
tests are included.
For example, I can now tell that libtomcat4-java and all its libraray
dependencies work with Kaffe 1.1.3. This does not mean that tomcat4 uses
all possible methods in these libraries. So IMHO it would be incorrect
for the all of them to depends on "kaffe | java2-runtime" since that
would imply that they fully work with Kaffe. That's why the application
that uses these libraries needs to depend on the known to be working
JVM(s) and runtime(s).
So, I don't know how far away sarge is, but maybe instead of getting
yourself flamed here, put up your commets at the above page and maybe
It's not flaming. It's just a discussion with some misunderstanding. ;-)
we get that implemented earlier than the next Debian release :)
Don't be so pessimistic about Debian releases! :-)
I hope to be able to read your proposal this weekend since you obviosuly
have addressed some of the problems that I tried so solve.
Stefan
Reply to: