On Wed, 2007-12-19 at 23:35 -0500, seth vidal wrote: > Not looked through the whole patch yet but some initial thoughts:
n/p you can have a few days :). > 1. this looks like a neat implementation. > 2.The size of the download if we include ALL of the changelog data is a > bit much. It ends up being a download of about 20M for fedora 8 > everything - then about half that for updates... So currently from: http://download.fedora.redhat.com/pub/fedora/linux/updates/8/x86_64/repodata/ ...other.sqlite.bz2 = 5.2MB and filelists.sqlite.bz2 = 2.4MB. Which is what we'd be downloading. The Fedora main repo. MD will only ever be downloaded once, and we could/should prime that at anaconda time (there's an open BZ on that anyway, due to having old MD being very bad). > We don't NEED the changelog data for depsolving/installs or even > searching. Maybe and option to not grab it at the same time? But, yeh, if it tried to download an extra 7.6MB a lot and you're on a modem ... I can see how painful that might be. I'd be tempted to recommend them just upping the metadata cache timeouts though. > Alternatively, the other direction to take this is to put a simple > heuristic into the cache grabbing: > > keep a count on the bad metadata per run per repo. If we get more > than 2? Then grab a tmp copy of the repomd.xml from the same mirror and > compare that one with our current copy. If the timestamp field of any of > the files is newer than the timestamp in the the one we have, then dump > the one we have and start over. I can probably implement that as an option if you want to see it. But are you sure we can change the MD after we've given it out? Eg. Something using the yum API calls repo.getPrimaryXML() parses the data and then calls repo.getFileListsXML() (which then changes the repoXML, and primary.xml) ... dito. for any other combination. -- James Antill <[EMAIL PROTECTED]> Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
