Description of problem: "yum update python3" failed on a rawhide (F17) guest machine. Running Transaction Check ERROR with transaction check vs depsolve: libgdbm.so.3()(64bit) is needed by avahi-ui-gtk3-0.6.30-4.fc17.x86_64 Please report this error in http://yum.baseurl.org/report You could try running: rpm -Va --nofiles --nodigest Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2011-10-11-12-18dREMGy.yumtx Note: I tried to file it in the upstream tracker, but was unable to. See bug 745204. Version-Release number of selected component (if applicable): [david@f17 ~]$ yum --version 3.4.3 Installed: rpm-4.9.1.1-2.fc16.x86_64 at 2011-08-16 18:33 Built : Fedora Project at 2011-08-15 10:16 Committed: Adam Jackson <ajax> at 2011-08-08 Installed: yum-3.4.3-4.fc16.noarch at 2011-08-16 18:44 Built : Fedora Project at 2011-07-15 20:11 Committed: James Antill <james at fedoraproject.org> at 2011-07-15 How reproducible: 100% right now on this guest. Actual results: I'll attach the log and the saved transaction file.
There was no output from: [david@f17 ~]$ rpm -Va --nofiles --nodigest
Created attachment 527496 [details] Output from "yum update python3"
Created attachment 527497 [details] Saved transaction file referenced by yum's error message
This is bizarre ... I don't see how the code can do this, and I'd expect this to have been tested a lot by usage. What do the following say: rpm -q --whatprovides 'libgdbm.so.3()(64bit)' repoquery -q --whatprovides 'libgdbm.so.3()(64bit)' sudo yum list gdbm compat-gdbm avahi-ui-gtk3 ...also wondering if this still happens with something like: sudo yum upgrade gdbm
Since filing the bug I upgraded "manually" via these steps: # yum remove avahi-ui-gtk3 (history id 165) # yum update update groff (history id 166) # yum update python3 (history id 167) I'm afraid I can't remember the exact error I ran into that led me to do ID 166 (I attempted "yum update python3" but ran into a conflict between duplicate files between groff and groff-base; looked like the package splitting in two) [david@f17 ~]$ rpm -q --whatprovides 'libgdbm.so.3()(64bit)' no package provides libgdbm.so.3()(64bit) [david@f17 ~]$ repoquery -q --whatprovides 'libgdbm.so.3()(64bit)' compat-gdbm-0:1.8.3-9.fc17.x86_64 gdbm-0:1.8.3-9.fc15.x86_64 [david@f17 ~]$ sudo yum list gdbm compat-gdbm avahi-ui-gtk3 Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Installed Packages compat-gdbm.x86_64 1.8.0-3.fc15 @fedora gdbm.x86_64 1.9.1-1.fc17 @rawhide Available Packages avahi-ui-gtk3.i686 0.6.30-4.fc17 rawhide avahi-ui-gtk3.x86_64 0.6.30-4.fc17 rawhide compat-gdbm.i686 1.8.3-9.fc17 rawhide compat-gdbm.x86_64 1.8.3-9.fc17 rawhide gdbm.i686 1.9.1-1.fc17 rawhide [david@f17 ~]$ sudo yum upgrade gdbm Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Setting up Upgrade Process No Packages marked for Update (already updated by ID 167 in the history, I think)
Pretty sure these are the same bug, not sure why people are hitting them now as I doubt this logic has changed in a long time. Looks like yum sees there is an update, and then doesn't check that the update helps ... in certain code paths. *** This bug has been marked as a duplicate of bug 745217 ***