>If yum instead did what you suggest, it may well be unable to find >packages that the Current metadata suggest, because it is trying the >stale mirror it downloaded the old metadata indicator from. that won't happen, because I did not say let's take a radon mirror, I said let's take the central secured mirror that all other mirrors are rsync from. >> Or perhaps my logic is absurd.. > > Your logic is not absurd. If yum downloaded all the metadata from one > point then that point would be come a bottleneck, badly. I did not say all the meta data but just repomd.xml it's a very small file (2.7K) that have filenames and their checksums, take a look at the output of wget -O - http://download1.rpmfusion.org/free/fedora/development/i386/os/repodata/repomd.xml 2>/dev/null or wget -O - http://download.fedoraproject.org/pub/fedora/linux/releases/9/Everything/i386/os/repodata/repomd.xml 2>/dev/null it looks like this <?xml version="1.0" encoding="UTF-8"?> <repomd xmlns="http://linux.duke.edu/metadata/repo";> <data type="other_db"> <location href="repodata/other.sqlite.bz2"/> <checksum type="sha">21e97d609abaf58c50661cb97d5c8aa2f07a962a</checksum> <timestamp>1210184312</timestamp> <open-checksum type="sha">62b710c5ae9677f7f95941e819c126406a138253</open-checksum> <database_version>10</database_version> </data> and this is for security reasons this way you will be sure that all the meta data are right because they match the checksum from on repomd.xml found on the trusted server _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
