[Copy to debian-policy, I don't read it but I prefer they know what's going on.]
I'm currently working on a Java architecture for Debian. We have, for a very long time, thanks to people like Stephen Zander, Java implementations for Debian (unfortunately most of them non-free, the free ones being often unusable). However, we do not have rules for laying out Java programs and/or libraries and (as a consequence?) many interesting Java stuff is still out of Debian. (I specially think of XML tools and of Biology programs). So, I wrote a draft of what could be the future Java policy (comments about it should probably be on the debian-java mailing list, which I read) <http://www.debian.org/~bortz/Java/policy.html>. It is important to note that it is absolutely not official. It has been discussed on debian-java but, unfortunately raised few messages. Now, I begin to package Java programs (expect the ITPs very soon, apart from Muffin,which I already announced) and I run into dependencies problems. The draft policy specifies a java-common package, whose everybody should depend on. So, I I follow my own draft, I need to depend on java-common and, since it doesn't exist yet (because the Java policy has not been blessed in any way), I cannot install. To solve the problem, I would like to create and upload three packages: - java-common (modeled after emacen-common for Emacs stuff), which will hold the policy, - java-virtual-machine-dummy, both in the case some Java VM do not Provide it yet and also the comply with the policy (defining a proper CLASSPATH, which will be done by a wrapper around the real Java VM), - java-compiler-dummy, both in the case some Java compilers do not Provide it yet and also the comply with the policy (defining a proper CLASSPATH, which will be done by a wrapper around the real Java compiler).
