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 [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
