On Mon, 2005-10-17 at 23:16 -0400, Luke Macken wrote:
> Smart mirror selection will hopefully become a part of urlgrabber/yum in
> the near future, but in the mean time I wrote a plugin,
> fastestmirror[0], for yum (>= 2.4.0) to quickly determine the fastest
> download mirror.
Now *that's* great! I've been maintaining manual mirror lists for ages,
because yum would always pick the most lethargic ones first...
Allow me to report a bug, while we're at it :)
The plugin apparently just tries to connect to the server, without
accessing any file. For me, this sometimes puts mirrors on top that
aren't going to serve me:
Downloading Packages:
Determining fastest mirrors
* mirror.cs.wisc.edu : 0.231959 secs
* mirror.linux.duke.edu : 0.272655 secs
* planetmirror.com : 0.323417 secs
* planetmirror.com : 0.306678 secs
* mirror.switch.ch : 0.343030 secs
... lots more...
http://mirror.cs.wisc.edu/pub/mirrors/linux/download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/dhclient-3.0.2-24.FC4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Date: Tue, 18 Oct 2005 03:31:54 GMT
Server: Apache
Content-Length: 310
Connection: close
Content-Type: text/html; charset=iso-8859-1
Trying other mirror.
http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/4/i386/dhclient-3.0.2-24.FC4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Date: Tue, 18 Oct 2005 03:31:54 GMT
Content-Length: 345
Accept-Ranges: bytes
Content-Type: text/html
Server: lighttpd/1.3.14
Trying other mirror.
... the third mirror works...
I suppose if the plugin tried to get a metadata file that should be
identical on all mirrors this effect could be avoided. Then again, those
files are being fetched from a random mirror anyway before the actual
downloads even start. Maybe, when this feature gets integrated into yum,
mirror selection could be combined with metadata download? Those files
could be too big, though, and could cause mirror selection to take a
long time...
Cheers
Steffen.
Attachment:
signature.asc
Description: This is a digitally signed message part
