On Thu, 2007-12-20 at 00:26 -0500, James Antill wrote: > 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. >
That's true, we can't. We'd have to shut it all down and restart the process again - which could mean depsolving again. It's a double edge. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
