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):
4.4.2-3

How reproducible:
Always

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.