Red Hat Bugzilla – Bug 164953
RFE: java dependency tracking
Last modified: 2007-11-30 17:11:11 EST
Description of problem:
Right now, dependencies in Java .class and .jar files aren't tracked by RPM, so
package maintainers are manually tracking deps with Requires: statements in
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Java-based package A, which depends on classes in package B-foo,
which is represented by a manual dependency in package A's .spec file.
2. Upgrade package B, which now includes the files which were previously
erroneously split out into package B-foo.
3. Curse your fate.
RPM laughs at you. yum laughs at you. up2date laughs at you. They're all
laughing at you. Are you going to take that? From *them*?
Your upgrade succeeds and you manage to hold on to your sanity for one more day.
The proposed solution assumes that:
* Tracking dependencies at the class level is sufficient. We could attempt to
track at the level of fields and members (with type and signature checking), but
the ability to provide fields and members through inheritance makes the problem
much harder to solve.
* The output of jcf-dump won't change in a way which breaks the scripts. If
that happens, jcf-dump may have to be replaced with a compiled program.
* $CLASSPATH is irrelevant.
* A needed class won't be provided by more than one package.
* We won't start satisfying cross-package deps using classes which have been
compiled to native code using gcj.
Created attachment 117381 [details]
Script to check for Java dependency closure on an installed system.
Created attachment 117382 [details]
Java .class/.jar provides scanner
Created attachment 117383 [details]
Java .class/.jar requires scanner
Nalin, step 2 is a packager error. There is a whole community of people looking
after the collection of those packages to prevent such things to occur. That is
why our Java packages _must_ be maintained upstream, at jpackage.org, and just
_imported_ into beehive.
The need to be on the watch for the dependencies and convert them into either
RPM dependencies, or Maven dependencies is intrinsic on the Java language and
there are even efforts (under the JCP, so we can't participate) to address these
If you have any suggestions on how to improve the Java packaging with RPMs I
suggest you bring them up at the firstname.lastname@example.org list.
Added to rpm-4_4 cvs, should be in rpm-4.4.3-0.4 when built. Thanks for the patches.
FInished lashing up java(...) autodetection this morning. FIxed in rpm-4.4.3-0.48.