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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
