repo-mirrorlist quality control?

[Ralf Corsepius]

On 02/25/2015 09:45 PM, Kevin Fenzi wrote:
> On Wed, 25 Feb 2015 18:58:54 +0100
> Ralf Corsepius <rc040203 at freenet.de> wrote:

>> I.e. when updating the master repository on the server, we emptied
>> our mirrorlists, and let the _master_ poll repomd.xmls from the
>> _mirrors_. When it found a mirror's "repomd.xml" was in sync, the
>> mirrors was re-add to our mirrorlists on the server.
>
> Right, so this would be a 'add when updated' rather than 'remove if
> outdated' model.
Correct.

> I'm not sure it would work too well for us because we
Neither am I.

> have so many repomd's to consider and it would take a while to crawl
> all mirrors for those to re-add. But it's a thought. We do keep the
> previous one in the metalink too, so that might help with overlaps (ie,
> add if either previous or current)
>
> I guess there's 56 repomd.xml's on the active fedora releases, plus
> another 42 for epel.
The project I've referring to had about the same number of repomd.xmls, 
but we only had ~3-4 mirrors.

>> As I am heavily using mock, I am fairly often seeing this issue with
>> mock. With mock w/ rawhide I am even observing hard build-breakdowns
>> (Seems to me as if something in f21's mock was changed to not let it
>> use mirrors)
>
> huh. Mock did change in rawhide to use dnf... not sure if thats
> related however.

I don't think dnf is to blame. I see f21's mock accesses a repository 
named "build" for rawhide. Something I can not find in my 
/etc/mock/fedora-rawhide-*.cfg, but which seems to be utterly slow and 
unreliable.

End-effect is, mock setting up chroots for rawhide often (almost always) 
is magnitudes slower than for other releases and often is bombing out 
for reasons, which I assume to be networking or remote repo 
accessibility issues.

To cut a long story short - My observation is: When mock-building a 
package for fc21 takes 1 minutes, mock-building the same package for 
rawhide takes much longer (5-10 minutes) and fails every now and then.

Ralf