Bug 164953 - RFE: java dependency tracking
RFE: java dependency tracking
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-08-02 21:06 EDT by Nalin Dahyabhai
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-25 11:48:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Script to check for Java dependency closure on an installed system. (799 bytes, text/plain)
2005-08-02 21:06 EDT, Nalin Dahyabhai
no flags Details
Java .class/.jar provides scanner (898 bytes, text/plain)
2005-08-02 21:07 EDT, Nalin Dahyabhai
no flags Details
Java .class/.jar requires scanner (1.12 KB, text/plain)
2005-08-02 21:08 EDT, Nalin Dahyabhai
no flags Details

  None (edit)
Description Nalin Dahyabhai 2005-08-02 21:06:38 EDT
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
.spec files.

Version-Release number of selected component (if applicable):

How reproducible:

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.
Actual results:
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*?

Expected results:
Your upgrade succeeds and you manage to hold on to your sanity for one more day.

Additional info:
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.
Comment 1 Nalin Dahyabhai 2005-08-02 21:06:39 EDT
Created attachment 117381 [details]
Script to check for Java dependency closure on an installed system.
Comment 2 Nalin Dahyabhai 2005-08-02 21:07:38 EDT
Created attachment 117382 [details]
Java .class/.jar provides scanner
Comment 3 Nalin Dahyabhai 2005-08-02 21:08:21 EDT
Created attachment 117383 [details]
Java .class/.jar requires scanner
Comment 4 Fernando Nasser 2005-08-03 14:34:25 EDT
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 jpackage-discuss@jpackage.org list.

Best regards,
Comment 5 Jeff Johnson 2005-08-25 11:48:01 EDT
Added to rpm-4_4 cvs, should be in rpm-4.4.3-0.4 when built. Thanks for the patches.
Comment 6 Jeff Johnson 2005-11-14 17:22:20 EST
FInished lashing up java(...) autodetection this morning. FIxed in rpm-4.4.3-0.48.

Note You need to log in before you can comment on or make changes to this bug.