Description of problem:
I had a fedora.repo set up like this:
name=Fedora $releasever - $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):
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.
No infinite loop. ;-)
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).
(In reply to comment #0)
> Description of problem:
> I had a fedora.repo set up like this:
> name=Fedora $releasever - $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
> 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:
...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.
> 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).
(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)
Author: Richard Hughes <email@example.com>
Date: Tue Sep 20 18:02:38 2011 +0100
Ignore metalink if a baseurl is specified
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.
Uhm, 0.92 is older than this commit, I guess 0.93 will be the first one with the fix.
(In reply to comment #4)
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.
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).