[Yum] [PATCH] metadata cache expiration fix

[seth vidal]

On Fri, 2006-07-14 at 10:34 -0400, Steve Magoun wrote:
> Hi,
> 
> My company is using yum 2.4.1 on our in-house derivative of Fedora  
> Core 4 to access an internal yum repository. We push out several  
> updates per day for testing. We've found that yum doesn't always find  
> the new updates, even though we use metadata_expire=0 in /etc/ 
> yum.conf. In at least one case this happens when the system clock is  
> set backward after an update; the timestamp on the cache file is then  
> in the future, and yum doesn't expire the cached metadata as  
> expected. We're using the following patch to work around the problem  
> (it should work for yumRepo.py on the CVS trunk as well). It's not a  
> complete solution to the problem of adjusted clocks, but it seems  
> appropriate for times when the user has indicated they don't want any  
> caching.
> 
> Steve Magoun
> Pepper Computer
> 
> 
> --- yum/repos.py.~1.83.2.2.~	2005-11-06 19:52:06.000000000 -0500
> +++ yum/repos.py	2006-07-14 10:03:33.000000000 -0400
> @@ -635,11 +635,12 @@
>           else return False"""
> 
>           val = False
> -        if os.path.exists(self.metadata_cookie):
> -            cookie_info = os.stat(self.metadata_cookie)
> -            if cookie_info[8] + self.metadata_expire > time.time():
> -                val = True
> -
> +        if self.metadata_expire != 0:
> +            if os.path.exists(self.metadata_cookie):
> +                cookie_info = os.stat(self.metadata_cookie)
> +                if cookie_info[8] + self.metadata_expire > time.time():
> +                    val = True
> +
>           return val
> 

I ended up doing something similar in cvs head.

Specifically, I added a check. If the ctime of the cooking file was
greater than the current time then assume the metadata needs updating.

oh and ntp or rdate is your friend.


-sv