[packagekit] yumbackend metadata_expire in mediarepo

[James Antill]

On Thu, 2009-07-30 at 10:32 +0100, Richard Hughes wrote:
> 2009/7/29 James Antill <james at fedoraproject.org>:

> >  Also I'm not sure why you set metadata_expire for all repos. with -1
> > when there is "no network", and then turn on caching only mode (the
> > later would do the same thing on it's own).
> 
> IIRC, I think I had some problem with setting
> self.yumbase.conf.cache=1 and then yum still accessing repos that were
> not yet setup -- would this make sense?

 No, that shouldn't happen and I'm pretty sure doesn't ... however
having a quick grep a huge number of functions seem to call
_check_init() and then manually always set ".yumbase.conf.cache = 0".
Which is likely the problem.

> > ¹ Or maybe this was supposed to go into refresh_cache() instead of the
> > weird hard coded update of some of the data, with no revert, hack that
> > is there atm.
> 
> I agree the code is pretty crazy right now. I think with lazy_cache we
> were trying to indicate that some things like getting the update list
> have to have a small cache age, and others like getting the group list
> could be much, much larger.

 Ahh, I see the desire there and in some ways it'd kind of be cool if
that worked but the cache works on the set of repodata so if yum updates
the repomd.xml then anything from the older version of the repomd.xml
which isn't the same in this one is gone. So you can't really have
different metadata_expire's for different parts of the repo. metadata.

 I'll try and give an example, as I'm not sure the above is readable
English :). If we have two versions of the repo. one we've already got
all of and one new one:

orepomd = old repomd.xml, timestamp=1
   primary_db = p1
   filelists_db = f1
   other_db = o1
   prestodelta = d1
   updateinfo = u1
   group = g1

nrepomd = new repomd.xml, timestamp=22
   primary_db = p2
   filelists_db = f2
   other_db = o2
   prestodelta = d2
   updateinfo = u2
   group = g2

...now as we go from orepomd to nrepomd yum will download everything in
the mdpolicy, and if that succeeds then it'll delete all the old data
(if it fails it reverts to the previous version). Eg. with
mdpolicy=group:small we end up with:

repomd = timestamp=22
   primary_db = p2
   filelists_db = <not available>
   other_db = <not available>
   prestodelta = <not available>
   updateinfo = u2
   group = <not available>

...(although we can then download groups if asked for, we can't revert
on failure) and with mdpolicy=group:main we'd get:

repomd = timestamp=22
   primary_db = p2
   filelists_db = f2
   other_db = <not available>
   prestodelta = d2
   updateinfo = u2
   group = g2

...the idea being that you set the mdpolicy to the pieces of data you
need and then some version of them are always available.

-- 
James Antill <james at fedoraproject.org>
Fedora