I'm not sure how a difference between what yum <-> rpm compute
for depsolving solutions somehow becomes an rpm "bug", particularly
since yum is calling rpmtsCheck() solely to ensure that it gets the
same answer as rpm, and it is a yum error message, suggesting that
you report the bug to a yum mailing list, where they have chose to close
Invalid. Whatever ...

Yes, I realize the above doesn't help you solve your problem.

What would be helpful is to see what rpm reports when given
exactly the list of packages that led to the yum failure.

And, for extra credit, add -vv, and examine the resultant spewage
for the unresolved dependencies. rpm prints the result of every
dependency assertion failure if -vv is supplied.

 Panu, one thing missing from this BZ is:

# repoquery --whatprovides java
java-1.5.0-gcj-0:1.5.0.0-28.fc11.x86_64
java-1.6.0-openjdk-1:1.6.0.0-20.b14.fc11.x86_64

...so yum/rpm are upgrading from java-1.5.0-gcj-1.5.0.0-25.fc11.x86_64 to java-1.5.0-gcj-0:1.5.0.0-28.fc11.x86_64, both of which provide "java" (as does the openjdk version) ... yum is happy with this (as I think it should be) but rpm is saying that "java" is needed by installed pkgs. and refusing to do the update.

 Or am I missing something?

You are missing that there may be other dependencies than
   Provides: java
and
   Requires: java
involved.

The problem is that the yum output isn't giving the version requirements:

# rpm -Uvh java*rpm
warning: java-1.5.0-gcj-1.5.0.0-28.fc11.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
error: Failed dependencies:
        java >= 1:1.6.0 is needed by (installed) jna-3.0.9-4.fc11.x86_64
        java >= 1.7 is needed by (installed) bouncycastle-1.43-1.fc11.noarch
        java >= 1:1.6 is needed by (installed) sat4j-2.0.3-1.fc11.noarch
        java >= 1:1.6.0 is needed by (installed) icu4j-0:3.8.1-5.fc11.x86_64
        java >= 1.7 is needed by (installed) pdf-renderer-0-0.5.20090405cvs.fc11.x86_64
        java >= 1.7 is needed by (installed) bouncycastle-mail-1.43-1.fc11.noarch

# rpm -qa --provides | grep '^java ='
java = 1.5.0
java = 0:1.6.0

So I'm missing 1:1.6.0 and 1.7.

This is clearly a problem on my system caused by running:

   54  rpm -e java-1.6.0-openjdk java-1.6.0-openjdk-plugin --nodeps

But the yum message is still cryptic and incorrect.

Ok, so ...

% repoquery --requires jna-3.0.9-4.fc11.x86_64 --repoid=rawhide | fgrep java
java >= 1:1.6.0
% repoquery --requires bouncycastle-1.43-1.fc11.noarch --repoid=rawhide | fgrep java
java >= 1.7
% repoquery --provides java-1.5.0-gcj-1.5.0.0-28.fc11 --repoid=rawhide | fgrep "java "
java = 1.5.0

...I'm not sure what java-1.6.0-sun-1.6.0.13-1cora.i586 provides, but I'd guess 1.6.0 without the epoch. So I'd guess that "package-cleanup --problems" will show that there are existing problems, and yum doesn't care but rpm does.

 Orion you want to fix the problems with the installed packages, and then everythign should work.

 Bah, wrote that a before your comment ... stupid mid-air collision with uselessness.

 We display the error message exactly as it comes from librpm, basically doing:

        results = []
        for prob in self.ts.problems():
            results.append(prob)
[...]
                retmsgs = [_('ERROR with rpm_check_debug vs depsolve:')]
                retmsgs.extend(results) 

...so I can see if Panu can fix the messages we get.

the yum message or the rpm message is cryptic and incorrect?

FYI: rpm is limited to 18 messages that can be returned
because of the insanities of i18n encoding and limitations
imposed by (lack of) API's to what can be supplied to
callers through callback.

Yes, the rpm message is cryptic (as in hard to understand)
and incorrect (as in misleading). But certainly its exactly
the same message that has _ALWAYS_ been returned
for exactly the same dependency failure(s) as _ALWAYS_.

Changing the messages leads to instant incompatibilities imho.
Been that way since like forever.

YMMV, have fun!

The rpm message is fine, and it pointed me to the problem quickly (although I am an experienced user).  This though is not helpful:


ERROR with rpm_check_debug vs depsolve:
java is needed by (installed) jna-3.0.9-4.fc11.x86_64
java is needed by (installed) bouncycastle-1.43-1.fc11.noarch
java is needed by (installed) sat4j-2.0.3-1.fc11.noarch
java is needed by (installed) icu4j-0:3.8.1-5.fc11.x86_64
java is needed by (installed) pdf-renderer-0-0.5.20090405cvs.fc11.x86_64
java is needed by (installed) bouncycastle-mail-1.43-1.fc11.noarch
Complete!
(1, [u'Please report this error in http://yum.baseurl.org/report'])

It doesn't give version numbers and seems to indicate a possible bug in yum code.

Orion, yum is just displaying what we get from librpm. Which is why I asked if Panu could fix "the messages we get".

Well this is now an rpm, not a yum, "bug". WIth suggested fix
changing rpm error messages. But otherwise I agree, the yum
message is quite misleading, as is the mindless re-mapping
of bugs to rpm instead of yum. One might much more easily
attempt the reproducer and think a bit.

Back to rpm messages ... here are the flaws:

1) The "needed by" that is hardwired in the message text is
very very difficult for transalators to render faithfully.

2) rpm-python abused the message text as an exception
qualifier. That is the concrete that locked rpm into 18
(and *only* 18) messages, becuase the message text
(with misspellings of "available") suddenly becomes
a program control flow, not an informational, problem.

3) Note the conflicting usage cases, where i18n for "display"
purposes of the message text, while must be identical is
needed for control flow purposes.

And here is Yet Another yum flaw ...

The API to extract problem text for informational display
has existed for years, in fact was originally implemented
to rationalize the conflicting usage cases for error messages
returned from rpmlib through rp[m-python. Yum has steadfastly
refused to use the problem set API (see "exactly" in comment #6
if you don't believe me).

I should qualify "steadfastly refused".

Sure the code snippet uses self.ts.problems().
That is not the issue.

What is missing is to use self.ts.problems() *everywhere*,
and to clearly identify the strings as "for display purposes only".

Specifically, self.ts.problems() needs to be examined by yum after
a running transaction has failed with bindings to rpmtsRun(), and
after rpmtsOrder() and after rpmtsAddInstallElement(), *everywhere*
that yum wishes to deflect flaws to rpm instead.

Ahhah, James you're right, rpm-python is at fault for the incomplete string. This is essentially the same as bug 349091#c4: rpm-pythons ts.check() modifies the supposedly unmodifiable altNEVR string when constructing the tuples. This has gone unnoticed because strrchr() silently casts away the const on the string so no compiler warnings/errors are triggered.

Fixed upstream now.

Fixed in rpm-4.7.0-5.fc12, will pull to F11 too once past the zero-day update flood.

rpm-4.7.0-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/rpm-4.7.0-2.fc11

rpm-4.7.0-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.