On Mon, Jul 02, 2007 at 02:31:31PM -0400, seth vidal wrote: > On Mon, 2007-07-02 at 13:28 -0500, Michael E Brown wrote: > > > > The point is still valid. > > -- If mirrolist was http:// url, then look for expires: http response > > code and use that. How about: > > > > /etc/yum.repos.d/site.repo: > > [repo-name] > > ... > > mirrorlist_cache_enable = bool > > mirrorlist_cache_expire_method = [ http | manual ] > > default to manual for ftp:// and file:// URLs and http for http:// URLs > > mirrorlist_cache_expire = timespec (for manual only) > > default to a reasonable value (1 week) > > > > why add all that code when we can just check the timestamp on the file > we saved and compare it? How much benefit to the user are we enabling by > implementing all of the above? More options != more benefit.
I'm not proposing this in order to benefit users at all. I run a repo, and this would help me as the repository maintainer. My point would be this: the person running the repository *has* to be able to control caching of mirrorlist on the clients. Any other scheme is broken. And it would be really nice if that method were outside of the config file, using already well-established methods of cache control. I'm currently running into problems with my users having stale metadata as it is, and it is a pain to debug. I moved some directories last week and redid all of the createrepos, but I am getting sporadic reports that yum is trying to download from the new baseurl + old rpm path. Essentially the same problem as when rawhide went from Fedora/RPMS to just Fedora/, except in my case I added a dir. If we had better control over client caching, I wouldnt have this problem. I could implement repository changes the same way I would do DNS changes. Normal DNS zone would have timeout of 1 week. When I know I have a change coming up, I turn down the timeout to 1 day. The day before the change, I change the timeout to 1 hour. That way, when I make the change, I know that nobody will have stale cached data. Today with yum, I have no way, as a repository admin, to control how clients cache my data, and I would really like to have a lot more control. -- Michael _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
