[Yum-devel] YumRepository._loadRepoXML proposed changes

[seth vidal]

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