Java dependency analysis
Hello.
In conjunction with the slowly maturing java policy for debian,
I've put together a tool for automated java dependency analysis.
It is in concept similar to dpkg-shlibdeps, and as such, I was
wondering if it would be appropriate for it to be added to the
dpkg tool suite. (I originally was trying to get it added to
debhelper, but Joey's comments in response suggested that it
might be better to have the actual dependency analysis in
dpkg, with a wrapper which traversed an intall image for
appropriate files in debhelper.)
Anyway, I am seeking your opinions on including a java dependency
analysis tool in the dpkg package. As the tool is written now,
it uses the Archive::Zip perl module to read .jar files, and thus
the priorities for libarchive-zip-perl and libcompress-zlib-perl
would have to go from optional to standard.
I'm also seeking opinions on how tightly coupled this should be
to the shlibs system. The problems for java libraries are almost
identical to the problems for native shared libraries, and so
using the same system (or at least an extremely similar system)
for handling the problems seems reasonable.
Java also has the issue of runtime CLASSPATH determination, which
is a closely related problem, and should probably be handled by the
same system that deals with the package dependencies as a whole.
The main differences are (a) granularity on the individual library
instead of package level and (b) a need for very high performance,
since the CLASSPATH needs to be determined each time a program is
invoked (or perhaps the CLASSPATHs for all dependent programs could
be munged at package install/upgrade time, but that seems to break
modularity).
- Alex
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: