[Yum-devel] makecache process

[seth vidal]

On Fri, 2005-11-04 at 15:32 -0700, Michael Stenner wrote:
> On Fri, Nov 04, 2005 at 04:41:46PM -0500, seth vidal wrote:
> > We would also need to add a more informative message to yum to let the
> > user know what's going on if the yum lockfile is engaged while the
> > metadata is being read in for the regular run.
> 
> I'm not familiar with the locking and metadata subsystems, so forgive
> me if this is naive or incorrect.  When you only hit locking conflicts
> when yum is being run interactively twice, then fine.  If you have to
> hit the 4 am update job, then fine again.  If we're talking about
> something that runs every few hours, it pays to think carefully about
> it as collisions will get annoying.  If the metadata rebuild only
> takes a few (5-20) seconds, then no biggie.  I suspect that's the
> case, so fine one more time.

Right - we need it to not interrupt things and/or being annoying for
people.
I was thinking of something that runs every 6 hours. It means that
chances are good the metadata will be current. Then adjust yum so that
if the repomd.xml file is < 8 hours old don't check the repo for an
update.


> All that said, if you decide it's worthwhile, you might consider doing
> the following:
> 
>   a) on metadata update, build the metadata separately (no lock)
>      without removing the "real" metadata
>   b) lock the real metadata
>   c) swap in the new metadata
>   d) unlock

Good thinking - it's the same thing we do when me run createrepo to make
the change out of the metadata as atomic as possible.

The only problem is that sqlite cache is an incremental update. We don't
rebuild the whole sqlite db, we update it, deleting and adding entries
as necessary.

So we're going to run into an issue  since it can't reasonably be in
another dir.

I guess the operation that is the least dangerous is:
1. make a copy of the repo
2. update the sqlite cache
3. set the yum lock
4. move it back into place
5. unset the lock

-sv