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