[Plplot-devel] Debian policy on java libraries

[Andrew R. <and...@us...>]

I've checked the debian policy on java packages
( in /usr/share/doc/java-common/policy.txt.gz ).

The relevant policy on libraries is below. Looks like we should put
plplot.jar in /usr/share/java as plplot-version.jar with a symlink to
plplot.jar. The JNI wrapper plplotjavac_wrap.so should go in
/usr/lib/jni, again presumably with a version. This may have loading 
implications?  

I don't think it is worth splitting it into two packages for the architecture
dependent/independent parts.

Andrew

Debian java policy extract:
---------------------------

2.4 Java libraries

   Libraries are not separated between developers (-dev) and
   users versions, since this is meaningless in Java.

   Java libraries packages must be named libXXX[version]-java
   (without the brackets), where the version part is optional and
   should only contain the necessary part. The version part
   should only be used to avoid naming colisions. The XXX part is
   the actual package name used in the text below.

   Their classes must be in jar archive(s) in the directory
   /usr/share/java, with the name
   packagename[-extraname]-fullversion.jar. The extraname is
   optional and used internaly within the package to separate the
   different jars provided by the package. The fullversion is the
   version of that jar file. In some cases that is not the same
   as the package version.

   Some package must also provide a symbolic link from
   packagename-extraname.jar to the most compatible version of
   the available packagename-extraname-version.jar files.

   Java libraries must depend on the needed runtime environment
   (java1-runtime and/or java2-runtime) but should not depend
   (only suggest) java-virtual-machine.

   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, not to the core classes
   provied by a the runtime environment.

   Some Java libraries rely on code written in a "native"
   language, such as JNI (Java Native Interface) code. This
   native code is compiled into separate dynamic libraries which
   are loaded by the Java virtual machine at runtime.

   If a Java library relies on native code, the dynamic libraries
   containing this compiled native code should be installed into
   the directory /usr/lib/jni. These dynamic libraries should be
   shipped in a separate architecture-specific package named
   libXXX[version]-jni. The package containing the Java bytecode
   (generally libXXX[version]-java) should depend on this
   package.

   There may be situations, such as with very small packages,
   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.