[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#365408: marked as done ([POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk)

Your message dated Mon, 16 Aug 2010 08:36:14 +0200
with message-id <4C68DC5E.1090804@thykier.net>
and subject line [POLICY-PROPOSAL] Drop java*-runtime/compiler, create, classpath-jre/jdk, and java-jre/jdk
has caused the Debian Bug report #365408,
regarding [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
365408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365408
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

package: java-common
version: 0.24

Hi all,

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:
http://wiki.debian.org/Java/Draft

I'd like to reach a consensus about the attached patch before sending
other proposals.

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

iD8DBQFEU8ju4vzFZu62tMIRAlqPAJ0bi7Cv/BTQ8WTw1TCrqRpEXVrCRQCfUFxH
x4KgDEiCjdpFukjpoDqpXkc=
=qDAF
-----END PGP SIGNATURE-----

Index: policy.xml
===================================================================
--- 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>debian-java@lists.debian.org</email>">
 ]>
 
 <book>
@@ -18,11 +18,11 @@
     <edition>$Revision:$ $Date:$</edition>
     <authorgroup>
       <author>
-	<surname>Lundqvist</surname>
-	<firstname>Ola</firstname>
+	<surname>Vandyck</surname>
+	<firstname>Arnaud</firstname>
 	<authorblurb>
 	  <para>
-	    <email>opal@debian.org</email>
+	    <email>avdyk@debian.org</email>
 	  </para>
 	  <para>
 	    The current author of the java policy.
@@ -30,6 +30,15 @@
 	</authorblurb>
       </author>
       <author>
+	<surname>Lundqvist</surname>
+	<firstname>Ola</firstname>
+	<authorblurb>
+	  <para>
+	    <email>opal@debian.org</email>
+	  </para>
+	</authorblurb>
+      </author>
+      <author>
 	<surname>Bortzmeyer</surname>
 	<firstname>Stephane</firstname>
 	<authorblurb>
@@ -45,7 +54,7 @@
 	<authorblurb>
 	  <para>
 	    Most issues of the java policy have been discussed on the
-	    <email>debian-java@lists.debian.org</email> mailinglist.
+	    &djava; mailinglist.
 	  </para>
 	</authorblurb>
       </author>
@@ -83,7 +92,7 @@
       Feel free to report comments, suggestions and/or disagreements to the
       java-common package (<email>java-common@packages.debian.org</email>)
       or the Debian Java mailing list
-      <email>debian-java@lists.debian.org</email>. Change requests should
+      &djava;. Change requests should
       be sent as a bug to the java-common package.
     </para>
 
@@ -93,8 +102,8 @@
     <title>Policy</title>
     
     <para>
-      Virtual packages are created: &jc;, &j2c;,
-      &jvm;, &j1r; and &j2r;.
+      Virtual packages are created: &jjre;, &jjdk;,
+      &cjre; and &cjdk;.
     </para>
 
     <para>
@@ -111,10 +120,10 @@
     <para>
       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
-      package.
+      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.
     </para>
 
     <para>
@@ -126,38 +135,27 @@
       <title>Virtual machines</title>
       
       <para>
-	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
-	environment.
+	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).
       </para>
 
       <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,
-	packages that do not implement the methods from Java 1.1 that have been
-	deprecated in Java 2 must not provide &j1r;.
-      </para>
-	
-      <para>
 	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.
       </para>
+
       <para>
 	They &should; have a CLASSPATH predefined which include the needed
 	runtime environment.
       </para>
       
       <para>
-	If a given source (like the JDK does) brings both a compiler and a
-	virtual machine, you &may; name the compiler package xxxx-dev.
-      </para>
-      
-      <para>
 	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.
       </para>
-    </sect1>
-    
-    <sect1 id="policy-compiler">
-      <title>Java compilers</title>
-      
-      <para>
-	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;).
-      </para>
 
       <para>
-	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.
       </para>
-
     </sect1>
     
     <sect1 id="policy-programs">
       <title>Java programs</title>
       
       <para>
-	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
 	<ulink url="http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.9";>Policy
 	  10.9</ulink>), for instance CLASSPATH. They &must; respect the Policy
@@ -199,21 +184,25 @@
 	<ulink url="http://www.debian.org/doc/debian-policy/ch-docs.html#s13.1";>
 	  Policy 13.1</ulink>).
       </para>
+
       <para>
-        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
-        libraries.
+        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
+       <filename>/usr/share/&lt;package&gt;</filename>.
       </para>
+
       <para>
-        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.
       </para>
+
       <para>
-        There is no naming rules for programs, they are ordinary programs,
-	from the user point of view.
-      </para>
-    </sect1>
+        There is no naming rules for programs, they are ordinary
+	programs, from the user point of view.  </para> </sect1>
     
     <sect1 id="policy-libraries">
       <title>Java libraries</title>
@@ -249,19 +238,15 @@
       </para>
 
       <para>
-        Java libraries &must; depend on the needed runtime environment
-	(&j1r; and/or &j2r;) but &should; not depend (only suggest)
-	java-virtual-machine.
-      </para>
-
-      <para>
 	All jar files &must; have a well-documented CLASSPATH, so 
 	that developers should know what to add to their wrappers.
       </para>
 
       <para>
-	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.
       </para>
 
       <para>
@@ -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
+  <filename>/usr/share/java</filename>.
       </para>
+
+      <para>
+  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.
+      </para>
+
+      <para>
+  Java libraries &must; be built with debug symbols on and &must; not
+  depend on any runtime.
+      </para>
+
     </sect1>
 
     <sect1 id="policy-politics">

--- End Message ---
--- Begin Message --- 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi

I am closing this bug which is marked wontfix. Parts of it has been
accepted (the removal of the java-compiler packages).

On a related note: there has been an increasing interest in the Java
Team to get openjdk-6 supported on all architectures.

If you believe this policy proposal is still relevant, please do not
hesitate to write back.

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAkxo3F0ACgkQVCqoiq1YlqzHyACg7gtmbQcEfBRPPnyfDpUOMgM/
vbkAmwdVSCYkYYp7col9+fZIVmmYQTEq
=uUbZ
-----END PGP SIGNATURE-----

--- End Message ---
Reply to: