On Fri, 7 Nov 2008, Muayyad AlSadi wrote: >> 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 Better yet, provide a cryptographic signature of the repomd.xml - which yum now supports. Or, alternatively, provide all the mirror info in a file like repomd.xml - but in the metalinks format, which yum also now supports. :) -sv _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
