Description of problem: Enable the f7 updates-testing repo. Try and upgrade perl. The yum transaction ends with: ERROR with rpm_check_debug vs depsolve: Package perl-devel needs perl(ExtUtils::Embed), this is not available. Package perl-devel needs perl(ExtUtils::Embed), this is not available. Complete! Version-Release number of selected component (if applicable): yum-3.2.2-1.fc7.noarch How reproducible: yum --enablerepo=updates-testing upgrade perl.x86_64 I will also attach the output of: yum -d9 upgrade perl.x86_64.
Created attachment 161998 [details] output from yum -d9 upgrade perl.x86_64
Created attachment 162004 [details] output from yum 3.2.3 from git. Here's the output from the version in git.
Thanks for reporting this. The table of packages to be updated looks suspicious: Updating: perl x86_64 4:5.8.8-23.fc7 updates-testing 11 M Installing for dependencies: perl i386 4:5.8.8-18.fc7 fedora 10 M perl-libs i386 4:5.8.8-23.fc7 updates-testing 573 k and then, among "Updating for dependencies:" perl-ExtUtils-Embed is missing. What version of perl-ExtUtils-Embed do you have installed? I guess it is -18.fc7. So, when perl.x86_64 is set to be updated, and the "perl = 4:5.8.8-18.fc7" requirement for perl-ExtUtils-Embed-1.26-18.fc7.x86_64 is broken, yum decides to satisfy it by installing old "perl-4:5.8.8-18.fc7.i386," instead of updating perl-ExtUtils-Embed to -23.fc7.x86_64. Why on earth have yum decided to go this way? A wild guess: try to remove (or disable) the allowdowngrade plugin, perhaps yum will then be less eager to use obsolete package to satisfy a dependency. But anyway, yum should prefer solving these situations by upgrading the package which has just lost its requires.
okay, we have a couple of issues here. for everyone who can replicate something like this please run: rpm -Va --nofiles --nomd5 I just want to see how many of these are older errors polluting the rpmdb.
See also bug 253447 which looks like possibly related. In that case 'package-cleanup --problems' does not report any issues, and is it pretty obvious what to do to get things going there, but yum somehow is unable to figure that out. yum-3.2.2-3.fc8
20070824 set brought updates from yum-3.2.2-3.fc8 to yum-3.2.3-2.fc8 and from yum-metadata-parser-1.1.0-2.fc7 to yum-metadata-parser-1.1.2-1.fc8. After those yum is able to find out that an update of compat-db to 4.5.20-3.fc8 requires db4-devel and that, in turn, db4-cxx so bug 253447 can be closed. It looks like that after those yum updates now yum "updates for dependencies" packages which should be updated anyway. For example: Updating: neon-devel x86_64 0.27.0-1 development 157 k openoffice.org-calc x86_64 1:2.3.0-2.2.fc8 development 7.5 M openoffice.org-impress x86_64 1:2.3.0-2.2.fc8 development 1.6 M openoffice.org-math x86_64 1:2.3.0-2.2.fc8 development 1.3 M openoffice.org-writer x86_64 1:2.3.0-2.2.fc8 development 3.0 M Installing for dependencies: libtextcat x86_64 2.2-3.fc8 development 131 k Updating for dependencies: neon x86_64 0.27.0-1 development 107 k openoffice.org-core x86_64 1:2.3.0-2.2.fc8 development 78 M Seems a bit weird but so far I did not notice truly undesirable side-effects so possibly this is benign.
I think I'm getting the same problem with trying to update just rpm on F7: # yum update rpm Loading "changelog" plugin Loading "downloadonly" plugin Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package rpm.x86_64 0:4.4.2.1-1.fc7 set to be updated --> Processing Dependency: rpm = 4.4.2-46.fc7 for package: rpm-build --> Processing Dependency: popt >= 1.10.2.1 for package: rpm --> Processing Dependency: rpm = 4.4.2-46.fc7 for package: rpm-devel --> Processing Dependency: rpm = 4.4.2-46.fc7 for package: rpm-libs --> Processing Dependency: rpm = 4.4.2-46.fc7 for package: rpm-python --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package rpm-libs.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-build.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-python.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-devel.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package popt.x86_64 0:1.10.2.1-1.fc7 set to be updated --> Processing Dependency: rpm = 4.4.2-46.fc7 for package: rpm-libs --> Restarting Dependency Resolution with new changes. --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: rpm x86_64 4.4.2.1-1.fc7 nysa-updates 1.1 M Updating for dependencies: popt x86_64 1.10.2.1-1.fc7 nysa-updates 72 k rpm-build x86_64 4.4.2.1-1.fc7 nysa-updates 623 k rpm-devel x86_64 4.4.2.1-1.fc7 nysa-updates 5.5 M rpm-libs x86_64 4.4.2.1-1.fc7 nysa-updates 920 k rpm-python x86_64 4.4.2.1-1.fc7 nysa-updates 58 k Transaction Summary ============================================================================= Install 0 Package(s) Update 6 Package(s) Remove 0 Package(s) Total download size: 8.2 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug --> Populating transaction set with selected packages. Please wait. ---> Package rpm-libs.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-build.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-python.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package rpm-devel.x86_64 0:4.4.2.1-1.fc7 set to be updated ---> Package popt.x86_64 0:1.10.2.1-1.fc7 set to be updated ERROR with rpm_check_debug vs depsolve: Package rpm-libs needs rpm = 4.4.2-46.fc7, this is not available. Complete! when I run "rpm -Va --nofiles --nomd5", I get unsatisfied dependency: "Unsatisfied dependencies for TIVsm-BA-5.2.5-0.i386: libstdc++-libc6.1-1.so.2" That's ok though... I expected that one.
yum-3.2.4-2.fc7.noarch still fails for me (comment #7) in the same way. It looks like yum doesn't know to upgrade rpm-devel.i386 to the new version (and probably popt.i386 eventually if it would ever get that far). I can open a new bug report if this is a different bug from the original.
Comment #7 is due to rpm stopping being multilib in trees (but should be fixed now) and thus is a different bug. The main thing here seems to be fixed with 3.2.4-2
ouch, yes... things do look ok after coaxing the update: yum update rpm popt.i386 popt.x86_64 rpmdevtools :) thanks.