Bug#227587: [PROPOSAL] Java library dependencies
Hallo Stefan, Hi Ben,
I'm just cutting in here...
* Stefan Gybas wrote:
>Ben Burton wrote:
>You still have not answered my questions about JUnit: Which package do
>you want in Debian? A stripped version without Swing GUI in main or a
>full version in contrib? Which one do you want to ship with your custom
>projects? JUnit is free, even with the Swing GUI classes.
In this case: Use a striped down one.
I'm not sure, how far we can go with that. In teh new 'Common
Packaging page', gentoo guys ask for Support of gentoos 'USE' Flag. I
understood that as a way to remove/add functionality at builtime. I'm
not sure, how far the free VMs are, but if that's enought to get them
into main (-> packages compile, but will not work. And yes, I'm not a
debian-legal regular :) I've no idea, if that's 'free enough' ), we
might consider using such a system in debian packages as well. In a
normal build, use a empty USE flag and put a readme into the package,
which add the information, what USE Flag to set to get the rest of the
functionality with a sun-derived VM.
And BTW: it would be nice, if you have a look at
http://java.debian.net/index.php/CommonJavaPackaging, adding your
thoughts as well. The problems you are discussing here are the exect
topic, which should be solved with that page.
My opinion to the rest:
* j2/1-runtime does not garantee anything *at runtime*, so it is
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)
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...
* 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...
[1] For the result, please see the bugreport at the java-common
package or use
deb http://www.katzien.de/debian/java ./
-> new-java-policy
[2] Unfortunatelly my scripts, as of now, also will not enforce such a
thing. Suggestions welcome, please add your thought to
http://java.debian.net/index.php/CommonJavaPackaging :)
[3] And you would still need a script, which enforces it at runtime...
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
we get that implemented earlier than the next Debian release :)
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: