Created attachment 817368 [details] transcript from console Description of problem: DNF leaves rpmdb in inconsistent state so YUM refuses to work with the database. Version-Release number of selected component (if applicable): dnf-0.3.11-3.git7bdc9e1.fc19.noarch How reproducible: ? What I did: 1. $ dnf upgrade 2. $ yum upgrade Actual results: YUM upgrade failed: $ yum upgrade Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit, versionlock Error: Package tuple ('ghostscript-cups', 'x86_64', '0', '9.07', '15.fc19') could not be found in rpmdb Expected results: It should work... Additional info: $ yum clean all solved the problem. See console.log for all the gory details.
Hello, as far as I can see from the output, ghotscript-cups was obsoleted and properly removed during the first transaction (performed by DNF in your case). So Yum shouldn't be looking for it---it is probably a problem of invalidating the Yum's cache when the actual state of RPMDB has changed.
Although it seems to be the most likely reason, I doubt dnf could run and finish a rpm transaction in less than 1 second after yum has saved the cache. Might be a FS issue ("version" file was updated, but "pkgtups-checksums" somehow was not). yum clean all" runs "yum clean rpmdb", so now we can't investigate the root cause. If it happens again, please reopen and attach a tar.gz of the /var/lib/yum/rpmdb-indexes/ directory (it should be quite small, under 100k)