On Sat, May 18, 2002 at 10:53:29AM -0700, T. Alexander Popiel wrote: > 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.
Well... This can be discussed... :) A perfect (?) solution would be to first search for things in your CLASSPATH and then /usr/share/java/*.jar, and if possible (or useful) search other places. This can give results like the following, which would be really great. Depends: libxalan-java | libxalan2-java It is probably not foolproof, but should be better than now. :) The problem is that we have to have a way to specify the CLASSPATH-dependencies and a general way to set this up. > 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? It would be great if the tool could resolve dependencies on jvm:s too. At least to specify a preferred jvm. This is not high priority though. You probably know better what is possible to perform. > 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. That would really be great. > 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? Only to/from .jars please. Actually I think the policy states that only jars should be used. If not please file a bug against java-common. > 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, Agreed. > 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. Agreed too. This nightmare have to be resolved. But install only .class-files is not a solution. There are too many packages "out there" that depend on a specific version. We should be able to have them working concurrently. > 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. Well one file is not a solution. There have to be some other and better mechanism for this. Each package should provide one (or several?) files that specify a CLASSPATH for the package (or jar?). But the specification for it have to be defiened. Suggestions are appriciated. > 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. It does not. A dh_javadepclasspath generated file can be a good starting point. Then we have to create a tool that can handle the different files and set up a CLASSPATH. > 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.) Yes it is probably useful, yes. > 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.) The best way I know if is dh_make in multiple pacakge mode. It is not very suitable though. The dh_make maintainers probably accept patches that allows for more than s/l/m to be created. :) Great job by the way. Regards, // Ola -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
