Bug 501068 - RFE: Fix different messages from rpm and librpm, on broken installed versioned requires
Summary: RFE: Fix different messages from rpm and librpm, on broken installed versione...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-15 19:32 UTC by Orion Poplawski
Modified: 2014-01-21 23:09 UTC (History)
6 users (show)

Fixed In Version: 4.7.0-2.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-03 13:54:13 UTC
Type: ---


Attachments (Terms of Use)

Description Orion Poplawski 2009-05-15 19:32:33 UTC
Description of problem:

# yum -y upgrade
Loaded plugins: downloadonly, refresh-packagekit
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package java-1.5.0-gcj.x86_64 0:1.5.0.0-28.fc11 set to be updated
---> Package java-1.5.0-gcj-devel.x86_64 0:1.5.0.0-28.fc11 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================
 Package                    Arch         Version                 Repository     Size
=====================================================================================
Updating:
 java-1.5.0-gcj             x86_64       1.5.0.0-28.fc11         rawhide       135 k
 java-1.5.0-gcj-devel       x86_64       1.5.0.0-28.fc11         rawhide        48 k

Transaction Summary
=====================================================================================
Install      0 Package(s)
Update       2 Package(s)
Remove       0 Package(s)

Total size: 183 k
Downloading Packages:
Running rpm_check_debug
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'])

Reported here:

http://yum.baseurl.org/ticket/117#comment:1

but closed invalid suggested rpm bug.

Version-Release number of selected component (if applicable):
yum-3.2.22-4.fc11.noarch
rpm-4.7.0-1.fc11.x86_64


I have some home built java-1.6.0-sun packages installed:

# rpm -qa java\*
java-1.5.0-gcj-devel-1.5.0.0-25.fc11.x86_64
java-1.5.0-gcj-1.5.0.0-25.fc11.x86_64
java_cup-0.10k-2.x86_64
java-1.6.0-sun-plugin-1.6.0.13-1cora.i586
java-1.6.0-sun-1.6.0.13-1cora.i586
java3d-1.3.2-1jpp.x86_64

[root@akialoa ~]# rpm -q --whatprovides java
java-1.5.0-gcj-1.5.0.0-25.fc11.x86_64
java-1.6.0-sun-1.6.0.13-1cora.i586
[root@akialoa ~]# yum list java\*
Loaded plugins: downloadonly, refresh-packagekit
Installed Packages
java-1.5.0-gcj.x86_64                       1.5.0.0-25.fc11                 installed
java-1.5.0-gcj-devel.x86_64                 1.5.0.0-25.fc11                 installed
java-1.6.0-sun.i586                         1.6.0.13-1cora                  installed
java-1.6.0-sun-plugin.i586                  1.6.0.13-1cora                  installed
java3d.x86_64                               1.3.2-1jpp                      installed
java_cup.x86_64                             1:0.10k-2                       installed
Available Packages
java-1.5.0-gcj.x86_64                       1.5.0.0-28.fc11                 rawhide
java-1.5.0-gcj-devel.x86_64                 1.5.0.0-28.fc11                 rawhide
java-1.5.0-gcj-javadoc.x86_64               1.5.0.0-28.fc11                 rawhide
java-1.5.0-gcj-src.x86_64                   1.5.0.0-28.fc11                 rawhide
java-1.6.0-openjdk.x86_64                   1:1.6.0.0-20.b14.fc11           rawhide
java-1.6.0-openjdk-demo.x86_64              1:1.6.0.0-20.b14.fc11           rawhide
java-1.6.0-openjdk-devel.x86_64             1:1.6.0.0-20.b14.fc11           rawhide
java-1.6.0-openjdk-javadoc.x86_64           1:1.6.0.0-20.b14.fc11           rawhide
java-1.6.0-openjdk-plugin.x86_64            1:1.6.0.0-20.b14.fc11           rawhide
java-1.6.0-openjdk-src.x86_64               1:1.6.0.0-20.b14.fc11           rawhide
java3d-demo.x86_64                          1.3.1-0.cte.2                   CoRA
java3d-javadoc.x86_64                       1.3.2-1jpp                      CoRA
java_cup-javadoc.x86_64                     1:0.10k-2                       rawhide
java_cup-manual.x86_64                      1:0.10k-2                       rawhide
javacc.x86_64                               4.1-0.3.fc11                    rawhide
javacc-demo.x86_64                          4.1-0.3.fc11                    rawhide
javacc-manual.x86_64                        4.1-0.3.fc11                    rawhide
javahelp2.noarch                            2.0.05-7.fc11                   rawhide
javahelp2-javadoc.noarch                    2.0.05-7.fc11                   rawhide
javasqlite.x86_64                           20090409-3.fc11                 rawhide
javasqlite-javadoc.noarch                   20090409-3.fc11                 rawhide
javassist.noarch                            3.9.0-1.fc11                    rawhide
javassist-javadoc.noarch                    3.9.0-1.fc11                    rawhide
javastroke.x86_64                           0.5.1-22.fc11                   rawhide

Comment 1 Jeff Johnson 2009-05-16 23:18:08 UTC
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.

Comment 2 James Antill 2009-05-18 13:45:32 UTC
 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?

Comment 3 Jeff Johnson 2009-05-18 13:57:54 UTC
You are missing that there may be other dependencies than
   Provides: java
and
   Requires: java
involved.

Comment 4 Orion Poplawski 2009-05-18 14:59:28 UTC
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.

Comment 5 James Antill 2009-05-18 15:18:42 UTC
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.

Comment 6 James Antill 2009-05-18 15:22:46 UTC
 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.

Comment 7 Jeff Johnson 2009-05-18 16:05:09 UTC
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!

Comment 8 Orion Poplawski 2009-05-18 16:13:20 UTC
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.

Comment 9 James Antill 2009-05-18 16:19:58 UTC
Orion, yum is just displaying what we get from librpm. Which is why I asked if Panu could fix "the messages we get".

Comment 10 Jeff Johnson 2009-05-18 16:31:54 UTC
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).

Comment 11 Jeff Johnson 2009-05-18 16:51:15 UTC
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.

Comment 12 Panu Matilainen 2009-05-19 07:53:05 UTC
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.

Comment 13 Panu Matilainen 2009-06-03 13:54:13 UTC
Fixed in rpm-4.7.0-5.fc12, will pull to F11 too once past the zero-day update flood.

Comment 14 Fedora Update System 2009-06-18 16:19:16 UTC
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

Comment 15 Fedora Update System 2009-07-11 16:54:46 UTC
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.


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