Hi I have compiled two patches against the current policy that I intend to apply Friday assuming there are no objections. p1_trival_changes.patch is a minor fix-up that will remove a duplicate clause and highlight some "policy" words (should, must etc) in addition to adding me to the author list. p2_fosdom06.patch is an adaption of the FOSDEM 06 draft[1]. The most apparent difference is that I have not included the "Java virtual machines" and "virtual packages" parts. The "virtual packages" is excluded due to #365408. The exclusion of "Java virtual machines" is because I have no knowledge of packaging JVMs and did not know if this was a feasible request. If you believe this should be added to the policy, please file a bug against java-common and I will add it in a later patch provided it is supported by the team. Applying these patches will close #505166 (p1) and#227587 (p2); furthermore I intend to tag #365408 as wontfix based on the feedback given. Please note that these patches will not bring the policy completely in line with how we do things now. They are intended to reduce the difference without being too large. Some of you may remember my last attempt to update the policy. I have not forgotten these changes, but the changes were done in a single large patch, which made it hard to review. I will convert the relevant changes from it into smaller patches. ~Niels [1] http://wiki.debian.org/Java/Draft
Description: Corrects a few keywords not being properly emphased and
updates the author list. It also remove mentions of some obsolete
JVMs and a duplicate clause.
Closes: #505166
--- policy.xml.orig 2010-03-22 20:05:02.335512811 +0100
+++ policy.xml 2010-03-22 20:04:35.248312944 +0100
@@ -3,6 +3,7 @@
"/usr/share/sgml/docbook/dtd/4.1/docbook.dtd"
[
<!ENTITY must "<emphasis>must</emphasis>">
+<!ENTITY mustnot "<emphasis>must not</emphasis>">
<!ENTITY may "<emphasis>may</emphasis>">
<!ENTITY should "<emphasis>should</emphasis>">
<!ENTITY jvm "<emphasis>java-virtual-machine</emphasis>">
@@ -18,6 +19,18 @@
<edition>$Revision:$ $Date:$</edition>
<authorgroup>
<author>
+ <surname>Thykier</surname>
+ <firstname>Niels</firstname>
+ <authorblurb>
+ <para>
+ <email>niels@thykier.net</email>
+ </para>
+ <para>
+ The current author of the java policy.
+ </para>
+ </authorblurb>
+ </author>
+ <author>
<surname>Lundqvist</surname>
<firstname>Ola</firstname>
<authorblurb>
@@ -25,7 +38,7 @@
<email>opal@debian.org</email>
</para>
<para>
- The current author of the java policy.
+ A previous author of the java policy.
</para>
</authorblurb>
</author>
@@ -98,21 +111,16 @@
</para>
<para>
- All Java code must be shipped as Java bytecode (*.class files, packaged
- in a *.jar archive) and with <quote>Architecture: all</quote>.
- </para>
-
- <para>
Packages written in Java are separated in two categories: programs
and libraries. Programs are intended to be run by end-users. Libraries
are intended to help programs to run and to be used by developers.
</para>
<para>
- Both are shipped as Java bytecode (<filename>*.class</filename>
+ Both &must; be shipped as Java bytecode (<filename>*.class</filename>
files, packaged in a <filename>*.jar</filename> archive) and with
- an "Architecture: all" since Java bytecode is supposed to be portable.
- It may additionally be shipped as machine code, as produced for example
+ an "Architecture: all".
+ It &may; additionally be shipped as machine code, as produced for example
by the GNU Compiler for Java, in a separate architecture-specific
package.
</para>
@@ -135,11 +143,11 @@
<para>
Packages that contain a runtime conforming to the Java 1.1
- specification should provide &j1r;. Packages that contain a runtime
- conforming to the Java 2 specification should provide &j2r;.
- If a package conforms to both, then it should provide both; however,
+ specification &should; provide &j1r;. Packages that contain a runtime
+ conforming to the Java 2 specification &should; provide &j2r;.
+ If a package conforms to both, then it &should; provide both; however,
packages that do not implement the methods from Java 1.1 that have been
- deprecated in Java 2 must not provide &j1r;.
+ deprecated in Java 2 &mustnot; provide &j1r;.
</para>
<para>
@@ -301,8 +309,7 @@
<listitem>
<para>
If your source package can compile (correctly) only
- with non-free tools (the only free Java compilers seem to be
- guavac, gcj and jikes, it cannot go to main. If your package itself
+ with non-free tools, it cannot go to main. If your package itself
is free, it &must; go to contrib.
</para>
</listitem>
Description: Applies the FOSDOM 2006 draft. The original proposals have been
adapted to better fit the current time.
.
This excludes the "Java virtual machines" part based on feedback on #365408
URL: http://wiki.debian.org/Java/Draft
Closes: #227587
--- policy.xml.orig 2010-03-22 20:04:35.248312944 +0100
+++ policy.xml 2010-03-22 21:42:34.535497348 +0100
@@ -11,6 +11,9 @@
<!ENTITY j2r "<emphasis>java2-runtime</emphasis>">
<!ENTITY jc "<emphasis>java-compiler</emphasis>">
<!ENTITY j2c "<emphasis>java2-compiler</emphasis>">
+<!ENTITY d-jdk "<emphasis>default-jdk</emphasis>">
+<!ENTITY d-jbdep "<emphasis>default-jdk-builddep</emphasis>">
+<!ENTITY d-jdoc "<emphasis>default-jdk-doc</emphasis>">
]>
<book>
@@ -119,15 +122,19 @@
<para>
Both &must; be shipped as Java bytecode (<filename>*.class</filename>
files, packaged in a <filename>*.jar</filename> archive) and with
- an "Architecture: all".
- It &may; additionally be shipped as machine code, as produced for example
- by the GNU Compiler for Java, in a separate architecture-specific
- package.
+ an "Architecture: all". There are rare exceptions to this such as Eclipse
+ SWT. Exceptions to this rule can only be granted by the Java Team.
+ Requests &must; be sent to <email>debian-java@lists.debian.org</email>.
</para>
<para>
- This policy does not yet address the issue of documentation (for instance
- HTML pages made with javadoc).
+ The Java bytecode &may; additionally be shipped as machine code, as produced for example
+ by the GNU Compiler for Java, in a separate architecture-specific package.
+ </para>
+
+ <para>
+ Programs and libraries &should; enable JUnit tests, if these are present.
+ However, these tests &mustnot; lead to build failures.
</para>
<sect1 id="policy-vm">
@@ -257,9 +264,7 @@
</para>
<para>
- Java libraries &must; depend on the needed runtime environment
- (&j1r; and/or &j2r;) but &should; not depend (only suggest)
- java-virtual-machine.
+ Class files in a java library &must; be built with debug symbols.
</para>
<para>
@@ -295,8 +300,66 @@
architecture-specific and follow the usual libXXX[version]-java
naming convention.
</para>
+
+ <para>
+ Java library packages &should; compile the javadoc API of the
+ library. The API &must; link against the javadoc API of the
+ libraries it depends on. This includes the core java classes,
+ which are provided by &d-jdoc;. The API &must; be registered with
+ doc-base and &must; be installed in
+ <filename>/usr/share/doc/<package>/api/</filename> or
+ <filename>/usr/share/doc/<package>/api-<component>/</filename>.
+ </para>
+ <para>
+ The API &must; be place in a separate doc package. This package
+ &must; depend on the doc packages it was linked against.
+ </para>
</sect1>
+ <sect1 id="policy-gcj-native">
+ <title>Native Java Bytecode (gcj packages)</title>
+
+ <para>
+ Java bytecode compiled into native code is referred to as
+ gcj-code and packages containing gcj-code as gcj-packages.
+ </para>
+
+ <para>
+ Packages &mustnot; ship gcj-code without the permission of
+ the Java team (<email>debian-java@lists.debian.org</email>).
+ Source packages that shipped gcj-packages the 22th of March
+ 2010 have been given this permission through the
+ ratification of this policy.
+ </para>
+
+ <para>
+ Source packages compiling gcj-packages &must; Build-Depend on
+ &d-jbdep;. The gcj-packages &should; only be shipped for a selected
+ set of architectures.
+ </para>
+
+ <para>
+ The gcj-code &must; be installed in <filename>/usr/lib/gcj/</filename>
+ and shipped in a separately from the original jar file. The gcj-package
+ &must; also install the classmap file generated by aot-compile in
+ <filename>/usr/share/gcj/classmap.d/</filename>.
+ </para>
+
+ <para>
+ The gcj-package &must; call rebuild-gcj-db in the postinst and
+ postrm script, if rebuild-gcj-db is present.
+ </para>
+
+ <para>
+ The gcj-package &must; depend on the package providing the jar
+ file, it is a native compilation.
+ The package containing the jar file &must; declare either a
+ Suggests or a Recommends relationship on the gcj-package.
+ This relationship &may; be different between architectures.
+ </para>
+
+ </sect1>
+
<sect1 id="policy-politics">
<title>Main, contrib or non-free</title>
<para>
@@ -322,6 +385,8 @@
url="http://www.gnu.org/software/classpath";>GNU-Classpath</ulink> has
a list of free versions), it cannot go to main. If
your package itself is free, it &must; go to contrib.
+ Since java libraries do not have a runtime dependency,
+ this rule does not apply to them.
</para>
</listitem>
@@ -444,6 +509,11 @@
will be integrated in the policy, one day).
</para>
</listitem>
+ <listitem>
+ <para>
+ Java packages &should; be built with &d-jdk; if possible.
+ </para>
+ </listitem>
</itemizedlist>
</chapter>
Attachment:
signature.asc
Description: OpenPGP digital signature