[Catalog-sig] Mirror list detection/construction - PEP 381

Paul Nasrat pnasrat at google.com
Thu Jul 22 01:32:02 CEST 2010

On Wed, Jul 21, 2010 at 8:20 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:10 PM 7/21/2010 +0100, Paul Nasrat wrote:
>> Given the fragility of this it seems that we might want to consider
>> alternative mirrorlist discovery mechanism.

> Non-random selection is tougher to implement, since you'd need to keep some
> kind of history to make it work effectively.  Determining the length of the
> list is a trivial problem by comparison.

Sure, it's not a hard problem in terms of computer science, but having
a well defined way to do this for mirroring, dependency resolving and
other clients seems like a reasonable request. But that selection is
going to be the responsibility of the clients, some may take the hit
to maintain a history and periodically update  or generate a confing
(cf fastestmirror plugin to yum or netselect-apt).

>From just picking up the PEP, reading it and using the information
therein to write a client implementation I think that the current
documented client code snippet does not do what the description
intends. It could be I'm misreading this, so if it is not the intent
that clients should be able to generate a list of mirrors to operate
on via last.pypi.python.org.

Is there any technical reason you'd want pypi clients to binary search
DNS to find the mirror end rather than a more directed lookup?


More information about the Catalog-SIG mailing list