The repositories are the same - they are just potentially out of sync.
END.
If they are not in sync then they are not the same.
If they are the same, then they don't need to both be listed as separate
repositories.
The aim is to maximize acces to local/close/deep mirrors without
losing
ability to get the latest parts from the master site (accessing the
master site is costly for the upstream source and potentially for the
user if it means leaving an intranet through a congested shared pipe).
You're mixing the concepts of repository and mirror in ways that they
shouldn't be mixed.
a repository is a set of packages - distinct from any other repository
in that it provides different items - they don't have to be discretely
different but at least not claiming to provide the identical things.
a mirror is an IDENTICAL COPY - hence the term mirror.
in yum it works like this:
[repo]
baseurl=mirror
mirror
mirror
mirror
[repo2]
baseurl=mirror2
mirror2
mirror2
mirror2
All the download manager should need is a list of the X upstream
level 1
sources, a list of all known mirror sources (sometimes a few 100 sites)
and be able to choose by itself 2-3 mirrors it'll poll and one upstream
source to check for completeness.
and if they're not in sync it will never know what it's getting - the
suggestion that you appear to be saying is allow repo2 to provide
something if repo fails.
What mirrors to hit can be determined with response time checks and
keeping stats on the bandwidth achieved/level of freshness of previous
accesses. (keeping track of the access hours might be smart too since
net topology radically changes when the US wakes up for example, plus by
correlating relative freshness with dates the program might even learn
each mirror sync hours over time)
again - this is all about the failover of identical mirrors. That's fine
- and that is why you can add options/cases to failover for that class -
look at failover.py in yum.
however, providing multiple repos that provide mostly the same thing and
expecting repo1 to failover for repo2 is a misuse of the concept.
All those checks are what a user is supposed to do manually before
putting a particular mirror in his config file. There is no reason
automating it can not give better results and produce more efficient
ressource usage patterns for everyone.
as long as a mirror is a mirror and not an alternate repo then listing
multiple mirrors under a repository stanza and doing statistic tracking
on them is not unreasonable. The tracking is not implemented and will
take some time to implement correctly.
-sv