Bug 253763 - yum dependency resolving problem with perl in f7 updates-testing
yum dependency resolving problem with perl in f7 updates-testing
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-21 15:10 EDT by Kevin Fenzi
Modified: 2014-01-21 17:59 EST (History)
3 users (show)

See Also:
Fixed In Version: 3.2.4-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-13 15:08:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from yum -d9 upgrade perl.x86_64 (691.47 KB, text/plain)
2007-08-21 15:10 EDT, Kevin Fenzi
no flags Details
output from yum 3.2.3 from git. (37.58 KB, text/plain)
2007-08-21 15:45 EDT, Kevin Fenzi
no flags Details

  None (edit)
Description Kevin Fenzi 2007-08-21 15:10:11 EDT
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.
Comment 1 Kevin Fenzi 2007-08-21 15:10:11 EDT
Created attachment 161998 [details]
output from yum -d9 upgrade perl.x86_64
Comment 2 Kevin Fenzi 2007-08-21 15:45:27 EDT
Created attachment 162004 [details]
output from yum 3.2.3 from git. 

Here's the output from the version in git.
Comment 3 Stepan Kasal 2007-08-21 16:11:59 EDT
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.
Comment 4 Seth Vidal 2007-08-21 16:40:06 EDT
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.
Comment 5 Michal Jaegermann 2007-08-25 11:44:12 EDT
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
Comment 6 Michal Jaegermann 2007-08-25 17:42:59 EDT
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.
Comment 7 Zing 2007-08-29 11:29:36 EDT
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.
Comment 8 Zing 2007-09-05 02:14:11 EDT
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 9 Jeremy Katz 2007-09-13 15:08:02 EDT
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
Comment 10 Zing 2007-09-13 18:42:47 EDT
ouch, yes... things do look ok after coaxing the update:

yum update rpm popt.i386 popt.x86_64 rpmdevtools 

:)

thanks.

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