Bug 739969

Summary:	zif (20110918) goes into infinite loop if .repo file contains both baseurl and metalink
Product:	[Fedora] Fedora	Reporter:	Kevin Kofler <kevin>
Component:	zif	Assignee:	Richard Hughes <hughsient>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	hughsient, jspaleta
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-20 20:14:41 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 Kevin Kofler 2011-09-20 15:12:57 UTC

Description of problem:
I had a fedora.repo set up like this:
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://sunsite.mff.cuni.cz/pub/fedora/$releasever/Everything/$basearch/os/
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

As a result, zif went into an infinite loop trying to fetch the metadata, where (according to the verbose output) it would fetch the repomd.xml, notice there's a metalink, try to fetch the metalink.xml, fail to fetch it because the baseurl doesn't contain it, decide to throw away the repomd.xml as well, go back to fetching it etc., ad infinitum.

I changed the file to just use the mirrorlist (hardcoding mirrors is no longer useful these days; I just commented out the baseurl= line), but it's still a bug in zif.

Version-Release number of selected component (if applicable):
zif-0.2.4-0.78.20110918git.fc15.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up a .repo file with both baseurl= pointing to a mirror and mirrorlist= pointing to a metalink, as described above.
2. Try to "zif update" or use PackageKit-zif.
  
Actual results:
Infinite loop.

Expected results:
No infinite loop. ;-)

Additional info:
I haven't saved the full debugging output, but I can reenable the baseurl line and paste the result if you need it (but you should be able to reproduce the issue yourself).

Comment 1 Richard Hughes 2011-09-20 16:51:28 UTC

(In reply to comment #0)
> Description of problem:
> I had a fedora.repo set up like this:
> [fedora]
> name=Fedora $releasever - $basearch
> failovermethod=priority
> baseurl=http://sunsite.mff.cuni.cz/pub/fedora/$releasever/Everything/$basearch/os/
> #baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
> mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch

I didn't know that was valid... What were you expecting to happen -- for baseurl to be used or metalink?

> As a result, zif went into an infinite loop

Eeek.

> I changed the file to just use the mirrorlist (hardcoding mirrors is no longer
> useful these days; I just commented out the baseurl= line), but it's still a
> bug in zif.

Agreed. This is what we do at the moment at startup:

https://raw.github.com/hughsie/zif/master/docs/startup-flow.svg

...which is complicated due to the way the repodata formats evolved. I'll see what I can do to work around this. It might be best just to ignore the baseurl if there's a mirrorlist. Ideas welcome.

Richard

Comment 2 Kevin Kofler 2011-09-20 16:58:54 UTC

> I didn't know that was valid... What were you expecting to happen -- for
> baseurl to be used or metalink?

TBH, I don't even know for sure what yum does with that… What I expected is that baseurl would be tried, and if the mirror isn't working, it'd fall back to the mirrorlist= entry (and the metalink in it).

Comment 3 Kevin Kofler 2011-09-20 17:00:53 UTC

(but there are also arguments for doing the opposite, as it'd allow having a mirrorlist, and falling back to the master server or an arbitrary mirror if the mirrorlist isn't responding)

Comment 4 Richard Hughes 2011-09-20 17:05:53 UTC

commit 23a60910bed0b956b2373b311b85461f3b93cccf
Author: Richard Hughes <richard>
Date:   Tue Sep 20 18:02:38 2011 +0100

    Ignore metalink if a baseurl is specified
    
    Resolves https://bugzilla.redhat.com/show_bug.cgi?id=739969

Note; there's also a note on the console explaining what we did. We can't fall back to the other if one isn't present as they are both the primary way of getting repomd.xml and in theory they could return different files.

Basically, if you hit this your repo file is broken.

Can you try with git master or zif-0.2.4-0.92.20110920git.fc16.src.rpm (or newer) please. Thanks.

Comment 5 Kevin Kofler 2011-09-20 17:14:29 UTC

Uhm, 0.92 is older than this commit, I guess 0.93 will be the first one with the fix.

Comment 6 Jef Spaleta 2011-09-20 17:27:52 UTC

(In reply to comment #4)
Richard,

I don't think its correct to say that metalink and baseurl options together represent a broken repo file.

man yum.conf    metalink section says this:
This can be used instead of or  with the baseurl option.

Yum very explicitly says that both options are allowed to exist together in a repofile.

I'd have to look more closely to be sure, but since yum supports a list of multiple baseurls to try, metalink information is most likely used to populate into that internal list along with the list of one or more urls listed with baseurl via comma separated syntax. And then failovermethod setting interacts with that internal url list as needed.


-jef

Comment 7 Kevin Kofler 2011-09-20 20:14:41 UTC

Infinite loop confirmed fixed in zif-0.2.4-0.93.20110920git (and yes, I removed the cached "fedora" directory before testing, to make sure it actually refetches all the metadata).