Bug 646790

Summary:	yum with skip-broken jump into infinite loop
Product:	[Fedora] Fedora	Reporter:	Marcela Mašláňová <mmaslano>
Component:	yum	Assignee:	Seth Vidal <skvidal>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	14	CC:	ffesti, james.antill, maxamillion, pmatilai, tim.lauridsen
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-05 13:18:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marcela Mašláňová 2010-10-26 09:03:04 UTC

Description of problem:
yum distribution-synchronization --releasever=14 --skip-broken
will be in infinite loop for ever.

I have rpmfusion repo set to rawhide and Fedora repos to 14. With skip-broken option was yum trying to find dependencies, after whole list skipped on start and do it again, because some dependencies couldn't be resolved. I resolved it by manual removal of problematic dependencies from rpmfusion and running withtou --skip-broken.

Version-Release number of selected component (if applicable):
yum-3.2.28-5.fc13.noarch

How reproducible:
yum distribution-synchronization --releasever=14 --skip-broken
with some unresolvable dependencies. In my case perl-MythTV from rpmfusion.

Steps to Reproduce:
1. enable rpmfusion in F-13
2. yum install perl-MythTV
3. disable rpmfusion, enable rpmfusion-rawhide
4. yum distribution-synchronization --releasever=14 --skip-broken
  
Actual results:
infinite loop

Expected results:
skip dependencies or stop

Additional info:

Comment 1 Tim Lauridsen 2010-10-27 05:09:07 UTC

Please add the output from

yum distribution-synchronization --releasever=14 --skip-broken -d9

Just break when the looping starts :)

Comment 2 Marcela Mašláňová 2010-10-28 16:59:41 UTC

...
looking for ('libxml2.so.2(LIBXML2_2.6.5)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('libxml2.so.2(LIBXML2_2.6.6)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('libxml2.so.2(LIBXML2_2.6.8)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('libxml2.so.2(LIBXML2_2.7.0)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('libxml2.so.2(LIBXML2_2.7.3)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('libz.so.1', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
looking for ('rtld(GNU_HASH)', None, (None, None, None)) as a requirement of libxml2-python.i686 0:2.7.7-1.fc13 - None
libxml2-python-2.7.7-1.fc13.i686 requires: libxml2 = 2.7.7-1.fc13
--> Processing Dependency: libxml2 = 2.7.7-1.fc13 for package: libxml2-python-2.7.7-1.fc13.i686
Potential Provider: libxml2.i686 0:2.7.7-1.fc13
Mode is u for provider of libxml2 = 2.7.7-1.fc13: libxml2.i686 0:2.7.7-1.fc13
Mode for pkg providing libxml2 = 2.7.7-1.fc13: u
Cannot find an update path for dep for: libxml2 = 2.7.7-1.fc13
Searching pkgSack for dep: libxml2
Checking deps for newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('newt', 'EQ', ('0', '0.52.11', '2.fc13')) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('python(abi)', 'EQ', ('0', '2.6', None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libc.so.6', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libc.so.6(GLIBC_2.0)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libc.so.6(GLIBC_2.1.3)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libc.so.6(GLIBC_2.4)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libnewt.so.0.52', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libnewt.so.0.52(NEWT_0.52)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('libnewt.so.0.52(NEWT_0.52.6)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
looking for ('rtld(GNU_HASH)', None, (None, None, None)) as a requirement of newt-python.i686 0:0.52.11-2.fc13 - None
newt-python-0.52.11-2.fc13.i686 requires: newt = 0.52.11-2.fc13
--> Processing Dependency: newt = 0.52.11-2.fc13 for package: newt-python-0.52.11-2.fc13.i686
Potential Provider: newt.i686 0:0.52.11-2.fc13
Mode is u for provider of newt = 0.52.11-2.fc13: newt.i686 0:0.52.11-2.fc13
Mode for pkg providing newt = 0.52.11-2.fc13: u
Cannot find an update path for dep for: newt = 0.52.11-2.fc13
Searching pkgSack for dep: newt
Checking deps for perl.i686 4:5.10.1-116.fc13 - None
^C^C^C^C^C^Z
[1]+  Stopped                 yum distribution-synchronization --releasever=14 --skip-broken -d9

Comment 3 Marcela Mašláňová 2010-10-28 17:02:54 UTC

The whole list is produced many times, but yum didn't try to update. 

Yum creates list of all dependencies, then it can't (probably) resolve one dependency and try again. I suppose you need more information for debug, so please ask.

Comment 4 Tim Lauridsen 2010-11-02 06:24:25 UTC

After thinking at little about the issue and looking at the skip-broken code, it looks like the code is made to work with obsoletes and updates but don't handle downgrades very well.

And I'm not sure it is a good path to take to try to solve the mayhem caused by downgrading a lot of packages in skip-broken :)
I will try to make some simple test case and see how it goes.

Comment 5 Marcela Mašláňová 2010-11-02 06:58:22 UTC

Yes, I agree skip-broken is not the best thing to do. But infinite loop is definitely not the good ;-)

Comment 6 Tim Lauridsen 2010-11-03 12:41:45 UTC

No, it is not good :)

Comment 7 Tim Lauridsen 2011-03-05 13:18:34 UTC


*** This bug has been marked as a duplicate of bug 681806 ***