Bug 253763

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.