Bug 739969 - zif (20110918) goes into infinite loop if .repo file contains both baseurl and metalink
Summary: zif (20110918) goes into infinite loop if .repo file contains both baseurl an...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: zif
Version: 15
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-20 15:12 UTC by Kevin Kofler
Modified: 2011-09-20 20:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-20 20:14:41 UTC


Attachments (Terms of Use)

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@hughsie.com>
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).


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