Re: Limitations for dh_javadeps
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 ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 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 debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: