Bug#548755: [Policy Update] Updating the java-policy to reflect current practices + small changes.

2009-09-28 Thread Niels Thykier
Package: java-common
Version: 0.33
Severity: normal
Tags: patch

Hi

I have made an attempt to bring the java policy up to date and made some 
small changes to make it more compatible with the Debian Policy.

Attached is a patch and a list of the changes. I have also provided these 
along with how it would look if this patch is applied at the following
website [#1].

To those of you, who already read my previous draft, please note that I
modified section [2] and [2.1] to [2.4]. The modifications done to
[2] and [2.2] to [2.4] is merely to mention the headless counterpart of
the javaX-runtime packages. However [2.1] has received a few more
modifications, where I have spelled out when a VM providing package may
provide a headless vs a non-headless.

~Niels

[#1] http://www.student.dtu.dk/~s072425/debian/policy/

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

java-common depends on no packages.

java-common recommends no packages.

Versions of packages java-common suggests:
ii  default-jre   1.6-33 Standard Java or Java compatible R
ii  equivs2.0.7-0.1  Circumvent Debian package dependen

-- no debconf information
Index: policy.xml
===
--- policy.xml	(revision 10638)
+++ policy.xml	(working copy)
@@ -2,14 +2,21 @@
 !DOCTYPE book PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN
 	/usr/share/sgml/docbook/dtd/4.1/docbook.dtd
 [
+!ENTITY may emphasismay/emphasis
 !ENTITY must emphasismust/emphasis
-!ENTITY may emphasismay/emphasis
+!ENTITY mustnot emphasismust not/emphasis
+!ENTITY not emphasisnot/emphasis
 !ENTITY should emphasisshould/emphasis
-!ENTITY jvm emphasisjava-virtual-machine/emphasis
 !ENTITY j1r emphasisjava1-runtime/emphasis
+!ENTITY j1rhless emphasisjava1-runtime-headless/emphasis
 !ENTITY j2r emphasisjava2-runtime/emphasis
-!ENTITY jc emphasisjava-compiler/emphasis
-!ENTITY j2c emphasisjava2-compiler/emphasis
+!ENTITY j2rhless emphasisjava2-runtime-headless/emphasis
+!ENTITY djdk emphasisdefault-jdk/emphasis
+!ENTITY djdkbd emphasisdefault-jdk-builddep/emphasis
+!ENTITY djhless emphasisdefault-jre-headless/emphasis
+!ENTITY djre emphasisdefault-jre/emphasis
+!ENTITY debpol http://www.debian.org/doc/debian-policy;
+!ENTITY d-j-list emaildebian-j...@lists.debian.org/email 
 ]
 
 book
@@ -18,6 +25,18 @@
 edition$Revision:$ $Date:$/edition
 authorgroup
   author
+	surnameThykier/surname
+	firstnameNiels/firstname
+	authorblurb
+	  para
+	emailni...@thykier.net/email
+	  /para
+	  para
+	The current author of the java policy.
+	  /para
+	/authorblurb
+  /author
+  author
 	surnameLundqvist/surname
 	firstnameOla/firstname
 	authorblurb
@@ -25,7 +44,7 @@
 	emailo...@debian.org/email
 	  /para
 	  para
-	The current author of the java policy.
+	The previous author of the java policy.
 	  /para
 	/authorblurb
   /author
@@ -69,21 +88,15 @@
 
 para
   There are several subpolicies in Debian. They all want to make
-  the
-  ulink url=http://www.debian.org/doc/debian-policy/;Debian
-	Policy/ulink
-  more precise when it comes to a specific subject. See
-  the Emacs subpolicy in package emacsen-common for instance.  As far as
-  I know, the only subpolicy for a programming language, is that of
-  ulink
-	url=http://non-us.debian.org/~hertzog/perl-policy.html/;Perl/ulink.
+  the ulink url=debpol;Debian Policy/ulink more precise
+  when it comes to a specific subject. See the Emacs subpolicy in
+  package emacsen-common for instance.
 /para
 
 para
   Feel free to report comments, suggestions and/or disagreements to the
   java-common package (emailjava-com...@packages.debian.org/email)
-  or the Debian Java mailing list
-  emaildebian-j...@lists.debian.org/email. Change requests should
+  or the Debian Java mailing list d-j-list;. Change requests should
   be sent as a bug to the java-common package.
 /para
 
@@ -93,12 +106,38 @@
 titlePolicy/title
 
 para
-  Virtual packages are created: jc;, j2c;,
-  jvm;, j1r; and j2r;.
+  Virtual packages are created: j1r;, j1rhless;, j2r; amp;
+  j2rhless;.
 /para
 
 para
-  All Java code must be shipped as Java bytecode (*.class files, packaged
+  The Java Team maintain a set of non-virtual packages providing a
+  default-java and may; be used as a concrete jave
+  implementation. They depend on a java implementation and provide
+  a symlink from filename/usr/lib/jvm/default-java/filename to
+  the selected java implementation.
+/para
+
+itemizedlist
+  listitem
+	para
+	  djre; - 

Bug#548755: [Policy Update] Updating the java-policy to reflect current practices + small changes.

2009-09-28 Thread Michael Koch
On Mon, Sep 28, 2009 at 06:04:33PM +0200, Niels Thykier wrote:
 Package: java-common
 Version: 0.33
 Severity: normal
 Tags: patch
 
 Hi
 
 I have made an attempt to bring the java policy up to date and made some 
 small changes to make it more compatible with the Debian Policy.
 
 Attached is a patch and a list of the changes. I have also provided these 
 along with how it would look if this patch is applied at the following
 website [#1].
 
 To those of you, who already read my previous draft, please note that I
 modified section [2] and [2.1] to [2.4]. The modifications done to
 [2] and [2.2] to [2.4] is merely to mention the headless counterpart of
 the javaX-runtime packages. However [2.1] has received a few more
 modifications, where I have spelled out when a VM providing package may
 provide a headless vs a non-headless.

Thanks for doing the hard work on this. We should really work to finish this,
finally.

There is one typo I saw: 'jave' should be 'Java'. There are also some
unneeded whitespace changes in the file which makes the diff just bigger.

I have also some issues with 2.4. The naming looks like its written in stone.
The problem is that you can use each Java program as library. Checkstyle
is a good example for this. For such cases we should define that its up to
the maintainer to decide.

Another issue is the jars need to be named like 'packagename-fullversion.jar'.
Some packages does not fullfil this. See bouncycastle. We should never need
to rename jars because of policy. We should always keep upstream jar name,
if possible (no conflicts with other software). Otherwise we will need to
adapt each software depending on that Java library.



Cheers,
Michael



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org