Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk
-----BEGIN PGP SIGNED MESSAGE-----
One of the result of our discussions in Oldenburg (devjam) and in
Bruxelles (FOSDEM) is about the use of the virtual packages.
One of our reflexion was the number in the java*-runtime and
java*-compiler was not useful anymore. First, nobody uses Java 1 and the
state of GNU Classpath is far better then Java 1.
For some informations, you can go to the draft:
I'd like to reach a consensus about the attached patch before sending
If you read the wiki, you'll notice I added a line with *later* so I
know where I have to re-start the futur proposals.
Note that I added a paragraph from a proposal from Stefan Gybas,
modified by Ben Burton (see Bug#227587). Even if they did not really get
a consensus, I think, with the change of the virtual packages to
classpath-jre, classpath-jdk, java-jre and java-jdk, the proposal of
Stefan is good to integrate in our policy.
I also integrated another proposal from Stefan Gybas, seconded by Ben
Burton (see Bug#227594). There was a consensus about it so I don't think
we need further discussion about this.
With this proposal, we can close:
- - this bug ;-) ;
- - #227587 (integrate the java libs dependency);
- - #227594 (integrate the removal of 'binfmt_misc');
- - #158984 (no more java 2 something);
- - #354026 (no more java*-runtime);
- - #166370 (because we have *-jdk and not *-compiler);
I attached a patch so it'd be easier to read.
Thanks for your comments or for seconding the proposal,
: :' :rnaud
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
--- policy.xml (revision 2101)
+++ policy.xml (working copy)
@@ -5,11 +5,11 @@
<!ENTITY must "<emphasis>must</emphasis>">
<!ENTITY may "<emphasis>may</emphasis>">
<!ENTITY should "<emphasis>should</emphasis>">
-<!ENTITY jvm "<emphasis>java-virtual-machine</emphasis>">
-<!ENTITY j1r "<emphasis>java1-runtime</emphasis>">
-<!ENTITY j2r "<emphasis>java2-runtime</emphasis>">
-<!ENTITY jc "<emphasis>java-compiler</emphasis>">
-<!ENTITY j2c "<emphasis>java2-compiler</emphasis>">
+<!ENTITY jjre "<emphasis>java-jre</emphasis>">
+<!ENTITY jjdk "<emphasis>java-jdk</emphasis>">
+<!ENTITY cjre "<emphasis>classpath-jre</emphasis>">
+<!ENTITY cjdk "<emphasis>classpath-jdk</emphasis>">
+<!ENTITY djava "<email>email@example.com</email>">
@@ -18,11 +18,11 @@
The current author of the java policy.
@@ -30,6 +30,15 @@
@@ -45,7 +54,7 @@
Most issues of the java policy have been discussed on the
- <email>firstname.lastname@example.org</email> mailinglist.
+ &djava; mailinglist.
@@ -83,7 +92,7 @@
Feel free to report comments, suggestions and/or disagreements to the
java-common package (<email>email@example.com</email>)
or the Debian Java mailing list
- <email>firstname.lastname@example.org</email>. Change requests should
+ &djava;. Change requests should
be sent as a bug to the java-common package.
@@ -93,8 +102,8 @@
- Virtual packages are created: &jc;, &j2c;,
- &jvm;, &j1r; and &j2r;.
+ Virtual packages are created: &jjre;, &jjdk;,
+ &cjre; and &cjdk;.
@@ -111,10 +120,10 @@
Both are 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
- by the GNU Compiler for Java, in a separate architecture-specific
+ an "Architecture: all" since Java bytecode is supposed to be
+ portable. It may additionally be shipped as BC (binary compatible)
+ compiled machine code, as produced by the GNU Compiler for Java,
+ in a separate architecture-specific package.
@@ -126,38 +135,27 @@
- Java virtual machines &must; provide &jvm; and
- depend on java-common. They can also provide the runtime environment
- that the package contains (&j1r; and/or &j2r;). If it does not
- provide the files itself it &must; depend on the needed runtime
+ Java virtual machines &must; depend on java-common. GNU Classpath
+ derived virtual machine &must; provide &cjre; and if they provide
+ development tools (replacements for javac, javadoc, rmic, etc) also
+ provide &cjdk;. Non-free JDKs &must; provide &jjre; (if they are a
+ runtime) and &jjdk; (if they also provide development tools).
- 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,
- packages that do not implement the methods from Java 1.1 that have been
- deprecated in Java 2 must not provide &j1r;.
They &should; use <filename>/etc/alternatives</filename>
for the name 'java' if they are command-line compatible with the
- Sun's java program.
+ Sun's java program. The same should be done for every other compatible
+ tool included in the runtime (e.g. rmiregistry) or development
+ (e.g. javadoc) package.
They &should; have a CLASSPATH predefined which include the needed
- If a given source (like the JDK does) brings both a compiler and a
- virtual machine, you &may; name the compiler package xxxx-dev.
Some Java classes implement their routines using a "native"
language (such as C). This native code is compiled and stored
in dynamic libraries (such as JNI modules) that are loaded at
@@ -165,33 +163,20 @@
include the directory <filename>/usr/lib/jni</filename> in its
search path for these dynamic libraries.
- <sect1 id="policy-compiler">
- <title>Java compilers</title>
- Java compilers &must; provide &jc; and/or &j2c; and depend on
- java-common. They &must; also depend on the needed runtime environment
- (&j1r; and/or &j2r;).
- They &should; use <filename>/etc/alternatives</filename>
- for the name 'javac' if they are command-line compatible
- with Sun's JDK javac. They &should; have a CLASSPATH predefined to
- include the java core classes need for the compiler.
+ Every runtime &must; use <filename>/usr/share/java/ext</filename> if
+ they provide an extension classloader to look for extension
+ librairies, but &may; look into additional directories.
- Programs &must; have executable(s) in
- <filename>/usr/bin</filename> and be executable. They can be Java
- classes (using binfmt_misc) or wrappers. In any case, they &must; run
+ Applications &must; provide one or more executable wrapper script(s) in
+ <filename>/usr/bin</filename>. They &must; run
without specific environment variables (see
10.9</ulink>), for instance CLASSPATH. They &must; respect the Policy
@@ -199,21 +184,25 @@
- If they have their own auxiliary classes, they
- &must; be in a jar file in <filename>/usr/share/java</filename>. The
- name of the jar &should; follow the same naming conventions as for
+ Additional classes in the package &must; be packaged in one or
+ more jars which can be put in
+ <filename>/usr/share/java</filename> (if they are intended to be
+ used by other programs) or into a private directory in
- Programs &must; depend on &jvm; and the needed
- runtime environment (&j1r; and/or &j2r;).
+ Programs &must; depend on the needed runtime/development environment
+ (&jjre;, &jjdk;, &cjre;, &cjdk;). If a program needs a special version
+ of a non-free runtime it &must; depend on this particular non-free
+ jre(s) (e.g. j2re1.5) and &must; not depends on a virtual package.
- There is no naming rules for programs, they are ordinary programs,
- from the user point of view.
+ There is no naming rules for programs, they are ordinary
+ programs, from the user point of view. </para> </sect1>
@@ -249,19 +238,15 @@
- Java libraries &must; depend on the needed runtime environment
- (&j1r; and/or &j2r;) but &should; not depend (only suggest)
All jar files &must; have a well-documented CLASSPATH, so
that developers should know what to add to their wrappers.
- This applies only to libraries, <emphasis>not</emphasis> to the core
- classes provided by a the runtime environment.
+ Java library packages &must; depend on other library packages if they
+ can't be used without them. If other libraries are only required by
+ parts of the library, they &may; suggest or recommend the required
+ library package instead.
@@ -285,8 +270,24 @@
where it is better to bundle the Java code and the native code
together into a single package. Such packages &should; be
architecture-specific and follow the usual libXXX[version]-java
- naming convention.
+ naming convention. The jar files be placed into
+ For certain cases, there is some Java code that depends on the
+ architecture (currently only SWT libraries). Architecture dependent
+ jars &must; be placed in <filename>/usr/lib/java</filename>. Very few
+ java packages belong to this category. Before uploading an
+ architecture dependent package a packager &must; ask on &djava; and
+ reach a consensus.
+ Java libraries &must; be built with debug symbols on and &must; not
+ depend on any runtime.