Gerry Reno <greno@xxxxxxxxxxx> writes: > I've been using the yum-fastestmirror plugin for doing our upgrades > this week and here are some observations. > > y-fm does not end up selecting the fastestmirror. It just picks > mirrors close to us. But these aren't the best mirrors. Kind of, it picks based on how long connect() takes. > y-fm should use some type of true throughput testing (yes this would > be slow but do it as a separate process in the background and build a > cache of results) then when yum starts up it just reads this file. Eventually we want this integrated into yum itself, so as it downloads data it tries to balance which mirror it uses to get the best throughput. But other things have to happen before we can start that (like moving to curl -- which has just started). However I'd highly recommend you look at: http://yum.baseurl.org/wiki/YumMultipleMachineCaching ...if you control more than one machine. > Some of the mirrors are broken. For instance, with F9 we were still > getting all the files in updates instead of the new PackageLibs and > transition files that then redirect to updates-newkey. Yum needs to > have some type of quality check by retrieving the metadata from a > known good source (fedora) and then comparing to the metadata > retrieved from the mirror. If they are different then you have a bad > mirror and it should go to the next mirror. This is mostly solved within yum, even by the Fedora 9 GA version, however it required changes to the repos. ... and those have only just happened with (soon to be) Fedora 11. Fedora 11 has "metalink" data to give yum the mirrors (so we can tell who is "too old"), and we have "unique metadata" so we just get a 404 if we hit a mirror that has different metadata than we want. -- James Antill -- james@xxxxxxx _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
