Steve M. Robbins wrote:
> Hi,
>
Hi
I have not had time to check your package and its build system (I may
have a look tomorrow if time permits).
> [...]
> The package I seek to create will contain several java libraries. I'm
> not packaging a program, nor a compiler, runtime, etc. My first
> question: is the policy document [2] sufficiently up-to-date for my
> needs?
>
No, it most certainly is not :). A set of policy changes have been
ratified during Easter that has not been deployed yet. I will look into
that tomorrow. I will write back when I get the policy deployed.
Mind you, even after this updated policy has been uploaded, it still
does not match all our practices. We are working on fixing this, but it
may take a while.
A notable change is that libraries no longer have to depend on a Java
Runtime. However, you should still ensure you always use java compiler
the package depend on and the "target" version of the class files are
correct.
Unlike the C-compiler (and e.g. python) javac uses the alternative
system. Depending on the build system in question you may have to set
either JAVA_HOME or tell it which javac (possible variables include
JAVACMD or JAVAC) it should use.
It is also the recommended practice to use default-jdk in Build-Depends
(/usr/lib/jvm/default-java). Though please note that while it uses
openjdk-6 on most archs, there are archs that does not support openjdk-6
where default-jdk is provided by gcj.
This may lead to build failures on these archs for many reasons. First
off, openjdk-6 contains some optional extensions which gcj does not
(e.g. some javax packages/classes). Furthermore gcj does not provide a
full java5 API, so valid java5 code may fail to compile due to gcj being
incomplete.
If you experience any problems getting the java package compiled on
some archs, do write back and we will see what we can do about it. We
got some of the extension packages/classes floating around in some of
our libraries packages.
The policy gained a clause about javadoc for libraries; but more on that
later when I get the policy deployed.
> By this, I mean is the advice in Section 2.4 still valid? The C++
> library SOVERSION is 3, so the C++ library package name is
> libinsighttoolkit3-dev. The java wrappers contain both jni code and
> java classes. Given this, I should create two packages named
> libinsighttoolkit3-jni and libinsighttoolkit3-java, right? The
> upstream sources create a jar named InsightToolkit.jar. In the -java
> package, shall I rename the jar InsightToolkit-3.18.0.jar with a
> symlink InsightToolkit.jar -> InsightToolkit-3.18.0.jar?
>
Yes, that sounds about right, though I think you can also just call the
packages libinsighttoolkit-{jni,java}. That is name it after the jar
file rather than the SONAME.
The version part from the policy is only to allow multiple versions of
the same java library in the archive (e.g. libservlet2.4-java and
libservlet2.5-java).
> There is no "dh_java". Are there any packaging scripts that might
> help me? Is there a good example package that I can learn from?
>
We got "javahelper" package which has an install-helper to rename the
jar and create the symlink for you. It may also have other useful
helpers for you.
It comes with a dh7 sequence (--with javahelper) if you use that.
Note that if your package comes with "pom"-files (for the maven build
system) you may want to use our maven helpers. Unfortunately I have not
used them myself, so I cannot help you with them.
> Thanks,
> -Steve
>
> [1] http://packages.qa.debian.org/i/insighttoolkit.html
> [2] http://www.debian.org/doc/packaging-manuals/java-policy/
>
~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature