Limitations for dh_javadeps

["T. Alexander Popiel" <popiel@wolfskeep.com>]

This is mostly directed to Ola Lundqvist, but I figure that
getting other people's opinions can't hurt. ;-)

I've gotten all the debhelper scripts and I've been pawing
through them, learning.  However, in the process, I've come
up with a couple more questions...

1. Should dh_javadeps only identify dependencies on .jars
   installed in /usr/share/java, should it search all installed
   packages for .jars, should it search for .jars anywhere in
   your CLASSPATH, or some combination of the above?

   I'm leaning towards searching /usr/share/java/*.jar plus
   anything in CLASSPATH.

2. Should dh_javadeps ignore any dependencies on classes in
   one of the java.* packages, assuming they will be handled
   by java-common and the JVM?

   I'm leaning toward yes, with version 2 of dh_javadeps perhaps
   identifying java1.1 vs. java2 dependencies based on which
   java.* classes get used.

3. Should dh_javadeps handle dependencies to/from raw .class
   files, or only from .jars?  Should the debian-java policy
   state that only .jars should be installed, not raw .class
   files?

   It's technically just as easy for me (finding the dependencies)
   either way, but organizationally, it would probably be better
   if everything installed only .jars.  On the other hand,
   CLASSPATH maintenance is going to be a nightmare if only .jars
   are allowed, since each .jar has to be separately named in the
   CLASSPATH, and debian policy doesn't give us any obvious good
   way to update the CLASSPATH when installing java libraries.

4. Should debian-java policy include a file which contains just
   a CLASSPATH setting including any and all java libraries, to
   be sourced by wrappers for java programs?  This file could be
   updated as appropriate by all java library packages.

   I'm somewhat in favor of this, although there are other solutions
   (such as a dh_javadeps-generated CLASSPATH explicitly in the
   wrappers for all java programs).  I'm not sure how well a shared
   file like this interacts with debian policy, though.

5. Would it be useful to folks if I made available a second dh_java*
   tool for taking a list of entry-point .classes and putting them
   (and all the .classes they depended on, excluding ones already
   in indicated .jars) into a .jar file?  (This is actually one of
   the functions of the tool that I'm munging to make dh_javadeps...
   and I personally find it quite useful for making minimal .jars
   out of a source tree containing multiple related programs.)

   I'm leaning towards yes on this, thinking that it could serve
   conceptually similar purpose as dh_movefiles in cases where
   multiple packages are built from a single source tree.
   Antlr comes to mind as a prime example, with a library and
   a code-generation tool as usefully distinct packages.

And now, for a personal-cluelessness whine:

6. Does anyone know of a good/simple way to set stuff up right
   to make both a library and a program package froma single
   source tree?  dh_make doesn't seem to handle this well, and
   I'm new enough at packaging that I'm not quite sure of the
   best way to approach this.  Any pointers would be greatly
   appreciated.  (Yes, I'm trying to package antlr this way,
   since it's the thing that I'm working with where my java
   code depends on code from a non-core java library... and
   thus could be used for testing all the dh_javadeps stuff.)

- Alex


-- 
To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org