Hello,
This is a draft for a Proposel to rearange most parts of the debian
java policy. Most of the things have been discusssed in the last
weeks and I hope I was able to get the main points into this draft.
The main goal about this proposal are
* get all the JVM out there working smoothly with debian and debian
package management.
* make the world for packagers a little easier.
I'm going to split this Proposel into little bits and add my
rational in the end. I will formalise this proposal based on coments
and rewrite it into a patch against current java-common.
It would be nice, if this, and the transition (if it should
happen...), are over before sarge is released.
I'm not a native english speaker, so I hope I at least get some
comments about my english :)
--- Should replace 2.1 and 2.2 ---
Java Runtime Environment and Java Development Environments
JRE
Java Runtime Environments, which are complient to the Java Spec of a
specific Version, have to provide the virtual package
'java2-runtime-<spec-version> and setup alternatives for
/usr/bin/java-<spec-version> and the corresponding manpage.
/usr/bin/java-<spec-version> needs to have all required API on its
bootclasspath, either by inclusion in rt.jar or by depending on
corresponding packages and adding the jars to the bootclasspath.
JDK
Java Development Environments, which are compilent to the Java Spec
of a specific version, have to provide the virtual package
java2-development-environment-<spec-version>. They also need to
provide a alternative for /usr/lib/java-dev-env-<spec-version>. This
dir must include bin/java, bin/javac, bin/javadoc and jini header
files. They may also add alternatives for
/usr/bin/javac-<spec-version> and /usr/bin/javadoc-<spec-version>
and the manpage for this commands.
Java Browser Plugin
Package, which include a java browser plugin, should provide the
virtual package java-browser-plugin-<spec-version> and
java-browser-plugin and setup a alternative for [do need to check,
where it actually is or needs to be].
/usr/bin/java will be contributed by a package java2-runtime, which
depends on any of the java2-runtime-<spec-version> and will be kept
for backward compatibility. It should not be used by official debian
packages; use the versioned virtual packages instead. Same will be
done with java2-compiler and java-browser-plugin
Priorities of the alternatives should be set as follows:
200 base points for the initial version of a new spec package
- 40 for not 100% spec complient alternatives
+ 30 if the alternative is DFSG free
+ x for each new revision (1.4.1_0 -> 10 points)
- 10 points, if the alternative is spec complient, but actually a
based on a higher spec (1.3 <-> 1.4)
---
Rational:
Currently, the java-virtual-maschine is of no use. Also, java
becomes more and more different, so that one can't depend on the
java2-runtime if one needs a 1.4 or higher /usr/bin/java.
Similar reasons apply to javac. Additionally, javac is mostly called
from scripts, which als need javadoc and other commands, so it is
mostly better to have set JAVA_HOME and be done with it.
/usr/lib/java-dev-env-<spec-version> should be such a JAVA_HOME.
The java browser plugin IMO does not needs such a tight dependency,
as most applets still use the 1.1.8 spec... I didn't bother with
c102 packages, as this will only be interesting for woody. As we
have a release plan aiming for first of December :)
--- added inbetween the above and "2.3 Programms" ---
Programms may honor the user set JAVA_HOME environment variable,
while looking for a java binary. If so, this should be clearly
stated in the manpage and other places, if possible. The programm
does not need to make sanity checks in this case.
---
This is mostly to make this official. Almost every package I've seen
so far does this.
Most of "2.3 Java Programms" will need to be replace by a updated
version (virtual package names). The part
|If they have their own auxiliary classes, they must be in a jar
|file in /usr/share/java. The name of the jar should folow the same
|naming conventions as for libraries.
should IMO be deleted: /usr/share/java will sometime be crouded and
in case of eclipse, it expects its internal jar files in specific
places, so I would need to make symlinks for no use. If the jar file
is interesting to be reused in other packages, it should be made a
separate package anyway (like just done with libant1.5-java).
The naming sheme and the symbolic link in "2.4 Libraries" should be
kept, so that setting up symlinks from other packages are possible
(eclipse sets a symlink to ant jars for example)
The classpath problem will be resolved by the following
proposal:
--- added to 'Libraries' ---
Classpath
To make classpath issues as easy as posible, each package, which
includes public jar files must add a jar-description-file (JarDF) in
/var/lib/java-classpath and place this jars in /usr/share/java.
JarDF must be named the same as the package, which contains them
(libant1.5-java -> /var/lib/libant1.5-java).
If more than package exports certain functionality, this packages
should use a virtual package name and the alternative system to
handle the coresponding JarDF.
A JarDF is a sh compatible file, which only sets variables. It must
set JARS and DEPENDS, even if they are empty. It may also add
CONTRIB, BOOTCLASSPATH, PROPERTIES and other variables, which may be
used privatly.
* JARS must be set with all the public jar files, seperated by ':':
JARS="/usr/share/java/first.jar:/usr/share/java/more.jar"
* DEPENDS must be a space or ':' seperated list of package, which this
jars need at runtime.
CONTRIB="otherpackage:libant1.5-java"
* CONTRIB is a likewise list of packages to which classpath the
public jars should be added. Example: a package contribute a task
to ant. This package would then have this CONTRIB line:
CONTRIB="libant1.5-java"
Packages, which have contribute there jars to classpath of other
packages need to cal the appropiated update-* script in the postrm
(in case of a removal) and postinst (update and new install)
scripts.
* BOOTCLASSPATH is a list of jars, as in JARS, whic should be added
to the bootclasspath. This is used to replace JVM API jars, like
a newer version of crimson XML parser.
* PROPERTIES is a list of properties, to pass to the virtual
maschine, on which this jars depend to be set on runtime.
---
-- added to programms ---
java-common will have a programm, which can be used to recieve the
classpath, bootclasspath and properties based on JarDF,
satisfying the specified DEPENDS.
Programms, which does not include public jar files may use the JarDF
system to handle their classpath as well.
---
I hope I got all common cases, which make classpath issues such a
pain. Packager should be able to specify their classpath in with
packages and don't need to bother, what names the jar files of this
packages have. Also, this helps, if several packages implement the
same API (like libswt or XML parsers -> Depend on the virtual
package name).
I will contribute a dh_java debhelper, which will work as follows:
* package.java
will be used to specify a Depends: line, as it should be used in
debian/control. If this file isn't present, the build-depends will
be used instead. Same for Bootclasspath.
* package.jars
will be installed in /var/lib/java-classpath. It may contain a
certain string, where dh_java will fill in the appropiated values,
like the 'DEPENDS="..."' and BOOTCLASSPATH="..." line based on the
above and also the 'JARS="..."' line (all *.jar files). If this
string isn't present and the variable isn't there as well, it will
be appended.
* postinst and prerm scripts will filled with the proper scrips
parts.
* debian/control -> package may have {java:Depends}, which will be
filled with the values from the first point.
* in binaries a certain string will be replaced with the right
package, so that the classpath can be computed.
More ideas wellcome...
I expect, that the transition from the old policy to this will work
without some sort of 'name appends' or similar. There are still just
a few java packages and updating should be fairy easy: mostly its
deleting stuff in debian/* and adding the dh_java call...
I will also try to send a patch to the mpkg-j2sdk author to make it
work with JREs as well and using this new virtual package names.
If this proposal is acepted, it would be really nice, if we could
get this script into sarge as well.
We should then update the java-FAQ to explain how to easily get a
installed java and java browser plugin and how to package (using
this new scripts and the CDBS classes.
In some bright and nice future, we could even have some lintian
warning for all this :) Ok, I expect that the sun will raise in the
west before this will happen... <g>
Thanks for going through this :)
Jan
