diff options
| -rw-r--r-- | Makefile | 39 | ||||
| -rw-r--r-- | debian/README.debian | 21 | ||||
| -rw-r--r-- | debian/changelog | 22 | ||||
| -rw-r--r-- | debian/control | 13 | ||||
| -rw-r--r-- | debian/copyright | 8 | ||||
| -rw-r--r-- | debian/dirs | 5 | ||||
| -rw-r--r-- | debian/docs | 1 | ||||
| -rwxr-xr-x | debian/rules | 71 | ||||
| -rw-r--r-- | html.dsl | 28 | ||||
| -rw-r--r-- | policy.sgml | 224 | ||||
| -rw-r--r-- | policy.xml | 224 |
11 files changed, 656 insertions, 0 deletions
diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..427017b --- /dev/null +++ b/Makefile @@ -0,0 +1,39 @@ +OUTPUTS=policy.html policy.txt policy.ps policy.db + +all: policy + +policy: policy.ps policy.txt policy.html + +policy.tex: policy.db + jade -t tex \ + -d /usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/print/docbook.dsl \ + /usr/lib/sgml/declaration/xml.decl $< + +policy.dvi: policy.tex + jadetex $< + jadetex $< + +policy.ps: policy.dvi + dvips -f $< > $@ + +policy.html: policy.db html.dsl + jade -t sgml \ + -d html.dsl \ + /usr/lib/sgml/declaration/xml.decl $< + +policy.txt: policy.db + jade -t sgml -V nochunks \ + -d /usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/html/docbook.dsl \ + /usr/lib/sgml/declaration/xml.decl $< > dump.html + lynx -force_html -dump dump.html > $@ + -rm -f dump.html + +validate: + nsgmls -s -wxml /usr/lib/sgml/declaration/xml.decl policy.db + +install: $(OUTPUTS) + install -m 0444 $(OUTPUTS) *.html $(DESTDIR)/usr/doc/java-common + +clean: + rm -f *.html *.aux *.log *.dvi *.ps *.tex *.txt + diff --git a/debian/README.debian b/debian/README.debian new file mode 100644 index 0000000..e7538c7 --- /dev/null +++ b/debian/README.debian @@ -0,0 +1,21 @@ +java-common for DEBIAN +---------------------- + +To build this package, you will need the DocBook apparatus: + +jade +jadetex +docbook-xml +docbook-stylesheets +sp +lynx + +and the packages they depend on, like tetex-*. + + +Another layout of the Policy is there: + +http://www.debian.org/~bortz/Java/policy.html + + +Stephane Bortzmeyer <bortzmeyer@debian.org>, Wed, 23 Jun 1999 15:03:43 +0200 diff --git a/debian/changelog b/debian/changelog new file mode 100644 index 0000000..fafecd7 --- /dev/null +++ b/debian/changelog @@ -0,0 +1,22 @@ +java-common (0.2) unstable; urgency=low + + * The policy is now included, and in XML form. Closes #42114 + + -- Stephane Bortzmeyer <bortzmeyer@debian.org> Thu, 2 Sep 1999 17:10:15 +0200 + +java-common (0.1) unstable; urgency=low + + * Proper versioning for a Debian-only package + + -- Stephane Bortzmeyer <bortzmeyer@debian.org> Mon, 28 Jun 1999 15:00:52 +0200 + +java-common (0.0-1) unstable; urgency=low + + * Initial Release. + + -- Stephane Bortzmeyer <bortzmeyer@debian.org> Wed, 23 Jun 1999 15:03:43 +0200 + +Local variables: +mode: debian-changelog +add-log-mailing-address: "bortzmeyer@debian.org" +End: diff --git a/debian/control b/debian/control new file mode 100644 index 0000000..e246bdc --- /dev/null +++ b/debian/control @@ -0,0 +1,13 @@ +Source: java-common +Section: misc +Priority: optional +Maintainer: Stephane Bortzmeyer <bortzmeyer@debian.org> +Standards-Version: 2.4.0.0 + +Package: java-common +Architecture: all +Depends: +Description: Base of all Java packages + This package is mandatory for any Java package. It + includes the Java policy. + diff --git a/debian/copyright b/debian/copyright new file mode 100644 index 0000000..af3c0e9 --- /dev/null +++ b/debian/copyright @@ -0,0 +1,8 @@ +It is a Debian original work. + +Upstream Author(s): Stephane Bortzmeyer <bortzmeyer@debian.org> + +Copyright: + +GPL. See /usr/doc/copyright/GPL. + diff --git a/debian/dirs b/debian/dirs new file mode 100644 index 0000000..700a193 --- /dev/null +++ b/debian/dirs @@ -0,0 +1,5 @@ +usr/bin +usr/sbin +usr/share/java +usr/share/java/repository +usr/doc/java-common diff --git a/debian/docs b/debian/docs new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/debian/docs @@ -0,0 +1 @@ + diff --git a/debian/rules b/debian/rules new file mode 100755 index 0000000..6945508 --- /dev/null +++ b/debian/rules @@ -0,0 +1,71 @@ +#!/usr/bin/make -f +# MAde with the aid of dh_make, by Craig Small +# Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess. +# Some lines taken from debmake, by Cristoph Lameter. + +# Uncomment this to turn on verbose mode. +#export DH_VERBOSE=1 + +build: build-stamp +build-stamp: + dh_testdir + + $(MAKE) policy + touch build-stamp + +clean: + dh_testdir + dh_testroot + rm -f build-stamp install-stamp + + # Add here commands to clean up after the build process. + $(MAKE) clean + -rm -f *~ + + dh_clean + +install: install-stamp +install-stamp: build-stamp + dh_testdir + dh_testroot + dh_clean -k + dh_installdirs + + # Add here commands to install the package into debian/tmp. + $(MAKE) install DESTDIR=`pwd`/debian/tmp + + touch install-stamp + +# Build architecture-independent files here. +binary-indep: build install + +# Build architecture-dependent files here. +binary-arch: build install +# dh_testversion + dh_testdir + dh_testroot + dh_installdocs + dh_installexamples + dh_installmenu +# dh_installemacsen +# dh_installinit + dh_installcron +# dh_installmanpages +# dh_undocumented + dh_installchangelogs +# dh_strip + dh_compress + dh_fixperms + dh_suidregister + dh_installdeb +# dh_shlibdeps + dh_gencontrol +# dh_makeshlibs + dh_md5sums + dh_builddeb + +source diff: + @echo >&2 'source and diff are obsolete - use dpkg-source -b'; false + +binary: binary-indep binary-arch +.PHONY: build clean binary-indep binary-arch binary diff --git a/html.dsl b/html.dsl new file mode 100644 index 0000000..b6fc449 --- /dev/null +++ b/html.dsl @@ -0,0 +1,28 @@ +<!-- + html.dsl - stylesheets for HTML output. + Stolen from SGMLtools +--> + +<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ +<!ENTITY docbook.dsl PUBLIC "-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" CDATA dsssl> +]> +<style-sheet> + +<style-specification id="html" use="docbook"> +<style-specification-body> + + +(define %html-ext% ".html") +(define %root-filename% "policy") +(define %generate-article-toc% #t) +(define %generate-article-titlepage% #t) +; (define %gentext-nav-use-tables% #f) + +;; Add other customization here + + +</style-specification-body> +</style-specification> + +<external-specification id="docbook" document="docbook.dsl"> +</style-sheet> diff --git a/policy.sgml b/policy.sgml new file mode 100644 index 0000000..221acca --- /dev/null +++ b/policy.sgml @@ -0,0 +1,224 @@ +<?xml version='1.0'?> +<!DOCTYPE article PUBLIC "-//Norman Walsh//DTD Simplified DocBk XML V3.1.3.6//EN" + "/usr/lib/sgml/dtd/docbook-xml/sdocbook.dtd"[ +<!ENTITY must "<emphasis>must</emphasis>"> +<!ENTITY may "<emphasis>may</emphasis>"> +<!ENTITY should "<emphasis>should</emphasis>"> +<!ENTITY repository "<filename>/usr/share/java/repository</filename>"> +]> + +<!-- I need a good way to add a <package> tag for names of the Debian + packages. XML experts may apply. --> + +<article> + <title>PROPOSED Debian policy for Java</title> + <artheader> + <author> + <surname>Bortzmeyer</surname> + <firstname>Stephane</firstname> + <authorblurb> + <para><email>bortzmeyer@debian.org</email></para> + </authorblurb> + </author> + <edition>Version 0.2, 2 september 1999</edition> + </artheader> + +<section><title>Background and metainfo</title> + +<para>An important warning: this text is +a <emphasis>proposal</emphasis>. I put it here, publically, so it can be read, +discussed, implemented, ignored, etc. It has no sort of endorsement +from any authority in Debian or elsewhere.</para> + +<para>Feel free to report me (Stephane Bortzmeyer +<email>bortzmeyer@debian.org</email>) comments and disagrements. I'll +put them on this text, if you don't object.</para> + +<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>. +</para> + +<para>This policy is intended to be in a package java-common, whose maintainer +will be Java Debian <email>debian-java@lists.debian.org</email>.</para> + +</section> + +<section><title>The policy</title> + +<para>A package java-common is created, containing this policy.</para> + +<para>Two virtual packages are created, java-compiler and +java-virtual-machine.</para> + +<para>Java compilers &must; provide java-compiler and depends on +java-common. They &should; use <filename>/etc/alternatives</filename> +for the name 'javac' if they are more or less command-line compatible +with Sun's JDK javac. They &should; have a CLASSPATH predefined which +includes &repository;.</para> + +<para>Java virtual machines &must; provide java-virtual-machine and +depends on java-common and use <filename>/etc/alternatives</filename> +for the name 'java'. They &should; have a CLASSPATH predefined which +includes &repository;.</para> + +<para>The problem of Java core classes is put on hold. In the mean time, Java +virtual machines are requested to come with their own core classes. (Or to depends +on another VM, like jikes does.)</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>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. +Both &must; depend on java-virtual-machine. </para> + +<para>Both are shipped as Java bytecode (<filename>*.class</filename> files, may +be packaged in a <filename>*.jar</filename> archive) and with an +"Architecture: all" since Java bytecode is supposed to be portable.</para> + +<para>Programs must have executable(s) in +<filename>/usr/bin</filename> and be executable. They can be Java +classes (using binfmt_java, in Debian <= 2.1 or binfmt_misc, in +Debian > 2.1) or wrappers. In any case, they &must; run without +specific environment variables (see <ulink +url="http://www.debian.org/doc/debian-policy/ch3.html#s3.8">Policy +3.8</ulink>), for instance CLASSPATH. They must respect the Policy +rules for executables (for instance a manual page per executable, see +<ulink +url="http://www.debian.org/doc/debian-policy/ch6.html#s6.1">Policy +6.1</ulink>). If they have their own auxiliary classes, they MUST be +either in a <filename>.jar</filename> in +<filename>/usr/share/java/PACKAGE-NAME.jar</filename> or use +the General Java Repository described below. Programs &must; depend on +java-virtual-machine.</para> + +<para>Libraries are not separated between developers (-dev) and users +versions, since it is meaningless in Java. Their classes MUST be either:</para> + +<itemizedlist> +<listitem><para>in a <filename>.jar</filename> archive + in <filename>/usr/share/java/PACKAGE-NAME.jar</filename></para> + </listitem> +<listitem><para>or in the General Java Repository.</para></listitem> +</itemizedlist> + +<para>In the first case, they &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.</para> + +<para>A General Java Repository is created by java-common in +&repository;. Classes which comply with the hierarchical packages +naming (for instance, gnu.getopt, com.foo.bar), &may; install classes +under it. It is expected that adding &repository; to the CLASSPATH is +enough to run any Java program which depends on such classes +(this &should; be done by Java virtual machines or compilers).</para> + +<para>This policy does not address the issue of documentation (for instance +HTML pages made with javadoc).</para> + +<para>There is no naming rules for programs, they are ordinary programs, from +the user point of view. Libraries packages &must; be named lib-XXX-java.</para> + +<para>About politics: packaging Java stuff changes nothing to the +rules Debian uses to find if a program is free or not. Since there are +not many free Java tools, keep in mind the following:</para> + +<itemizedlist> + +<listitem><para>If you source package can compile (correctly) only +with non-free tools (the only free Java compilers seems to be guavac +and gcj and may be jikes if it changes its licence), it +cannot go to main. If your package itself is free, it must goes to +contrib.</para></listitem> + +<listitem><para>If your binary package can run only with non-free +virtual machines (the only free Java virtual machine seems to be +kaffe), it cannot go to main. If your package itself is free, it must +goes to contrib.</para></listitem> + +</itemizedlist> + +</section> + +<section><title>Issues to discuss</title> + +<para>The following points are discussions about the policy, either +because they have to be studied more, or are controversial.</para> + +<itemizedlist> + +<listitem><para>Name of the Repository. There is a proposal to replace +it by simply <filename>/usr/share/java</filename>. (Per Bothner +<email>per@bothner.com</email>)</para></listitem> + +<listitem><para>Core classes (<filename>java.*</filename>). More study +needed.</para></listitem> + +<listitem><para>Versioned dependencies. Programs may have the need to +depend on a VM >= 1.2, for instance. Since dpkg does not have +versioned provides, it is difficult. Also, many people mistake JDK +versions for language versions. More studies of the Java Language +Specification needed (Adam Di Carlo +<email>adam@onshore.com</email>).</para></listitem> + +<listitem><para>Sun's Community Source Licence. Can we use it? How? +Where can we <ulink url="http://www.sun.com/software/communitysource/faq.html"> +find the text</ulink>? +</para></listitem> + +</itemizedlist> + +</section> + +<section><title>Advices to Java packagers</title> + +<para>Warning: they are just advices, they are not part of the policy.</para> + +<itemizedlist> + +<listitem><para>At the present time, there is no recommandation on +wether a library should use a <filename>.jar</filename> or the General +Java Repository. Some tools may require jars (for instance, for their +cryptographical signatures). It is the advice of the original author +of this policy that jars are almost useless for a local system +(applets on a network are a different thing).</para></listitem> + +<listitem><para>Be sure to manage all dependencies by hand in +<filename>debian/control</filename>. Debian development tools cannot +find them automatically like they do with C programs and libraries (or +like dh_perl does it for Perl, a volunteer to write dh_java would be +welcome).</para></listitem> + +<listitem><para>You can suppress many calls in +<filename>debian/rules</filename> which are meaningless for Java, like +dh_strip or dh_shlibdeps.</para></listitem> + +<listitem><para>Source package handling is painful, since most Java +upstream programs come with <filename>.class</filename> files. I +suggest to make a new <filename>.orig</filename> tarball after +cleaning them, otherwise, dpkg-source will complain.</para></listitem> + +<listitem><para>Java properties files are probably better under +<filename>/etc</filename> and flagged as configuration files (this +will be integrated in the policy, one day).</para> +</listitem> + +</itemizedlist> + +</section> + +</article> + + + + + + + + diff --git a/policy.xml b/policy.xml new file mode 100644 index 0000000..221acca --- /dev/null +++ b/policy.xml @@ -0,0 +1,224 @@ +<?xml version='1.0'?> +<!DOCTYPE article PUBLIC "-//Norman Walsh//DTD Simplified DocBk XML V3.1.3.6//EN" + "/usr/lib/sgml/dtd/docbook-xml/sdocbook.dtd"[ +<!ENTITY must "<emphasis>must</emphasis>"> +<!ENTITY may "<emphasis>may</emphasis>"> +<!ENTITY should "<emphasis>should</emphasis>"> +<!ENTITY repository "<filename>/usr/share/java/repository</filename>"> +]> + +<!-- I need a good way to add a <package> tag for names of the Debian + packages. XML experts may apply. --> + +<article> + <title>PROPOSED Debian policy for Java</title> + <artheader> + <author> + <surname>Bortzmeyer</surname> + <firstname>Stephane</firstname> + <authorblurb> + <para><email>bortzmeyer@debian.org</email></para> + </authorblurb> + </author> + <edition>Version 0.2, 2 september 1999</edition> + </artheader> + +<section><title>Background and metainfo</title> + +<para>An important warning: this text is +a <emphasis>proposal</emphasis>. I put it here, publically, so it can be read, +discussed, implemented, ignored, etc. It has no sort of endorsement +from any authority in Debian or elsewhere.</para> + +<para>Feel free to report me (Stephane Bortzmeyer +<email>bortzmeyer@debian.org</email>) comments and disagrements. I'll +put them on this text, if you don't object.</para> + +<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>. +</para> + +<para>This policy is intended to be in a package java-common, whose maintainer +will be Java Debian <email>debian-java@lists.debian.org</email>.</para> + +</section> + +<section><title>The policy</title> + +<para>A package java-common is created, containing this policy.</para> + +<para>Two virtual packages are created, java-compiler and +java-virtual-machine.</para> + +<para>Java compilers &must; provide java-compiler and depends on +java-common. They &should; use <filename>/etc/alternatives</filename> +for the name 'javac' if they are more or less command-line compatible +with Sun's JDK javac. They &should; have a CLASSPATH predefined which +includes &repository;.</para> + +<para>Java virtual machines &must; provide java-virtual-machine and +depends on java-common and use <filename>/etc/alternatives</filename> +for the name 'java'. They &should; have a CLASSPATH predefined which +includes &repository;.</para> + +<para>The problem of Java core classes is put on hold. In the mean time, Java +virtual machines are requested to come with their own core classes. (Or to depends +on another VM, like jikes does.)</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>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. +Both &must; depend on java-virtual-machine. </para> + +<para>Both are shipped as Java bytecode (<filename>*.class</filename> files, may +be packaged in a <filename>*.jar</filename> archive) and with an +"Architecture: all" since Java bytecode is supposed to be portable.</para> + +<para>Programs must have executable(s) in +<filename>/usr/bin</filename> and be executable. They can be Java +classes (using binfmt_java, in Debian <= 2.1 or binfmt_misc, in +Debian > 2.1) or wrappers. In any case, they &must; run without +specific environment variables (see <ulink +url="http://www.debian.org/doc/debian-policy/ch3.html#s3.8">Policy +3.8</ulink>), for instance CLASSPATH. They must respect the Policy +rules for executables (for instance a manual page per executable, see +<ulink +url="http://www.debian.org/doc/debian-policy/ch6.html#s6.1">Policy +6.1</ulink>). If they have their own auxiliary classes, they MUST be +either in a <filename>.jar</filename> in +<filename>/usr/share/java/PACKAGE-NAME.jar</filename> or use +the General Java Repository described below. Programs &must; depend on +java-virtual-machine.</para> + +<para>Libraries are not separated between developers (-dev) and users +versions, since it is meaningless in Java. Their classes MUST be either:</para> + +<itemizedlist> +<listitem><para>in a <filename>.jar</filename> archive + in <filename>/usr/share/java/PACKAGE-NAME.jar</filename></para> + </listitem> +<listitem><para>or in the General Java Repository.</para></listitem> +</itemizedlist> + +<para>In the first case, they &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.</para> + +<para>A General Java Repository is created by java-common in +&repository;. Classes which comply with the hierarchical packages +naming (for instance, gnu.getopt, com.foo.bar), &may; install classes +under it. It is expected that adding &repository; to the CLASSPATH is +enough to run any Java program which depends on such classes +(this &should; be done by Java virtual machines or compilers).</para> + +<para>This policy does not address the issue of documentation (for instance +HTML pages made with javadoc).</para> + +<para>There is no naming rules for programs, they are ordinary programs, from +the user point of view. Libraries packages &must; be named lib-XXX-java.</para> + +<para>About politics: packaging Java stuff changes nothing to the +rules Debian uses to find if a program is free or not. Since there are +not many free Java tools, keep in mind the following:</para> + +<itemizedlist> + +<listitem><para>If you source package can compile (correctly) only +with non-free tools (the only free Java compilers seems to be guavac +and gcj and may be jikes if it changes its licence), it +cannot go to main. If your package itself is free, it must goes to +contrib.</para></listitem> + +<listitem><para>If your binary package can run only with non-free +virtual machines (the only free Java virtual machine seems to be +kaffe), it cannot go to main. If your package itself is free, it must +goes to contrib.</para></listitem> + +</itemizedlist> + +</section> + +<section><title>Issues to discuss</title> + +<para>The following points are discussions about the policy, either +because they have to be studied more, or are controversial.</para> + +<itemizedlist> + +<listitem><para>Name of the Repository. There is a proposal to replace +it by simply <filename>/usr/share/java</filename>. (Per Bothner +<email>per@bothner.com</email>)</para></listitem> + +<listitem><para>Core classes (<filename>java.*</filename>). More study +needed.</para></listitem> + +<listitem><para>Versioned dependencies. Programs may have the need to +depend on a VM >= 1.2, for instance. Since dpkg does not have +versioned provides, it is difficult. Also, many people mistake JDK +versions for language versions. More studies of the Java Language +Specification needed (Adam Di Carlo +<email>adam@onshore.com</email>).</para></listitem> + +<listitem><para>Sun's Community Source Licence. Can we use it? How? +Where can we <ulink url="http://www.sun.com/software/communitysource/faq.html"> +find the text</ulink>? +</para></listitem> + +</itemizedlist> + +</section> + +<section><title>Advices to Java packagers</title> + +<para>Warning: they are just advices, they are not part of the policy.</para> + +<itemizedlist> + +<listitem><para>At the present time, there is no recommandation on +wether a library should use a <filename>.jar</filename> or the General +Java Repository. Some tools may require jars (for instance, for their +cryptographical signatures). It is the advice of the original author +of this policy that jars are almost useless for a local system +(applets on a network are a different thing).</para></listitem> + +<listitem><para>Be sure to manage all dependencies by hand in +<filename>debian/control</filename>. Debian development tools cannot +find them automatically like they do with C programs and libraries (or +like dh_perl does it for Perl, a volunteer to write dh_java would be +welcome).</para></listitem> + +<listitem><para>You can suppress many calls in +<filename>debian/rules</filename> which are meaningless for Java, like +dh_strip or dh_shlibdeps.</para></listitem> + +<listitem><para>Source package handling is painful, since most Java +upstream programs come with <filename>.class</filename> files. I +suggest to make a new <filename>.orig</filename> tarball after +cleaning them, otherwise, dpkg-source will complain.</para></listitem> + +<listitem><para>Java properties files are probably better under +<filename>/etc</filename> and flagged as configuration files (this +will be integrated in the policy, one day).</para> +</listitem> + +</itemizedlist> + +</section> + +</article> + + + + + + + + |