Repository feature proposal

seth vidal skvidal at phy.duke.edu
Sun Oct 19 20:43:39 UTC 2003


> > also - the mirroring information is tricky b/c most mirrors won't know
> > about the other ones - mirroring information is probably best left OUT
> > of the information for any one repository.
> 
> But the core org knows about it's official mirrors. And this official
> mirror list should be made available to the end-users download manager
> so it can choose automatically the closest/less loaded available mirror
> (maybe even spread the load between several mirrors).

untrue - they know about tier1 mirrors - but not tier2 or tier3.


> Relying on the users to uncomment a mirror in a list means most people
> won't bother and just hit the mother site.

have you seen how the mirrors are used for red hat's mirrors?
they use the first one in the list that responds in < 2s.

<snip xml sample>
and that seems simple to you?

if you're going to have that as the config file then you're going to
need a program to edit/manage those.


> If the download manager logic is properly implemented it will always use
> the new mirror instead of the others, because if you won't have added it
> to the list if it's worst than the official ones (ie it will always be
> closer/have more bandwidth available than the others).

the amount of data you'll have to include is growing and growing.

-sv






More information about the fedora-devel-list mailing list