Dear Debian Java packagers,
I've arranged for a Debian Java BOF at Debconf this year which I know many
people won't be at, so I'd like to have some sort of pre-discussion first.
There are a number of issues I'd like to try and sort out with packaging
policy, and actually try and get them baked into policy. Firstly, I think we
need to move most of the changes suggested at FOSDEM 2006[1] into the main
policy. I then have some large issues and a couple of small ones which I'd like
to address.
General issues:
- FOSDEM Draft
- Packaging tools
- Jar dependency resolution
- Transitions
FOSDEM Draft:
Library changes look good, particularly dropping runtime dependencies. Javadoc
is all sensible. Native and arch-dependent stuff is also all sensible. Unit
tests, shouldn't specifically refer to JUnit, but I think if the maintainer is
happy that there aren't any racy tests, failing the build on a failing unit
test is entirely reasonable. If it's a real regression, you really do want to
fail the build.
The virual package section from here has been superseded since and I think we
have a fairly sensible set of packages.
Packaging tools:
I've been trying to fill out as many useful tools as possible in javatools [2]
(javahelper/jarwrapper) to make it as simple as possible to package java
programs, including a CDBS class for them all. I'd love suggestions for more
tools or improvements to these.
jh_depends - turns a Class-Path manifest into Depends, also adds depends on
jarwrapper, VMs and virtual packages as appropriate.
jh_manifest - an easy way to update manifest files of the built jars.
jh_exec - any jars which are (linked to) the PATH are made executable
jh_build - very simple build system for jars
jh_installlibs - for installing jars to /usr/share/java with the correct
names and links
jh_makepkg - builds a template debian/ dir for a java program/library
including cleaning up common things from upstream.
java-propose-classpath - uses javap to find jars that it should be
depending on. Not automatable though due
to a. optional depends and b. multiple
jars with overlapping contents.
jarwrapper - uses binfmt-misc to run executable jar files.
Jar dependency resolution:
At the moment all programs need to know recursively all the jars which they
will use. This introduces unnecessary transitions when a library changes it's
dependencies, more work for packagers writing wrappers scripts, and long
classpath lines in them. Java already has a method for recursively generating
classpaths with the Class-Path: manifest entry and there are similar things
with Eclipse's OSI manifest extensions[3], whereas Gentoo use separate
gentoo-specific config files which are used for generating wrappers.
I think we should mandate one of the standardised ways of doing dependency
resolution so that in most cases application writers don't need to maintain
recursive classpaths; java -jar should work and therefore jarwrapper can be
used to avoid writing any wrapper at all (In fact, -jar doesn't work at all
without a Class-Path attribute as -cp is ignored, so we can't make use of the
Main-Class attribute either). It would also allow jh_depends to generate the
correct dependencies.
It may also be worth considering manifest extensions to do with class file
versions, so that when virtual packages are determined by jh_depends it can
recursively use class file versions to determine the minimum JVM version
required for running the program. At the moment it checks all the class files
in that package to generate the alternatives list.
Transitions:
I've mentioned the class-path issues relating to transitions. In general,
however, we don't have a good plan for transitions. I recently had to update
one of my packages in a rush because it FTBFS with the new version of a library
which didn't change package name. Now, we mandate that packages ship jars with
version-number-based file names, but because the packages aren't
co-installable, this isn't very useful.
I think we need to change to something more like the way C libraries use
sonames:
- the numbering in the filename should also be in the package
- it should be bumped for non-backwards-compatible changes
- possibly the symlink should be in some sort of dev package (with the javadoc?)
The javahelper tools can then resolve those symlinks to the correct filename /
package depends.
Specific (minor) issues:
- As #395372, Java policy should not restrict executables to /usr/bin, but
to anywhere which policy would normally allow
- #227594 suggests removing the section about binfmt_misc and class files.
I agree with this; using binfmt_misc for class files is a bad idea.
Only trivial applications are single class files with no classpath.
However, I think that executable jars with binfmt_misc are sensible
(see jarwrapper)
I propose that Java policy 2.3 is changed to the following:
Programs must have executable(s) in a location complient with the FHS
2.3 (See Policy 9.1.1). These must either be a wrapper script or a
symlink to an executable jar under /usr/share/java in which case they
must depend on jarwrapper and have a Main-Class attribute in the jar
Manifest. In any case, they must run without specific environment
variables (see Policy 10.9), for instance CLASSPATH. They must respect
the Policy rules for executables (for instance a manual page per
executable, see Policy 13.1).
...
- Currently the rest of 2.3 says that programs must have all the classes in
/usr/share/java. Programs which aren't expecting their classes to be used
as a library can surely ships jars in /usr/share/$program ?
Other suggestions of things we should discuss are also welcome, as would ideas
about how to integrate people who can't be at debconf into the discussion.
Relaying to IRC or using SIP to conference call people in, for example.
Matt
1. http://wiki.debian.org/Java/Draft
2. http://packages.debian.org/source/squeeze/javatools
--
Matthew Johnson
Attachment:
signature.asc
Description: Digital signature