[Yum-devel] how long to hold on to a mirrorlist

seth vidal skvidal at linux.duke.edu
Mon Jul 2 18:31:31 UTC 2007


On Mon, 2007-07-02 at 13:28 -0500, Michael E Brown wrote:
> On Mon, Jul 02, 2007 at 01:28:22PM -0400, seth vidal wrote:
> > On Mon, 2007-07-02 at 11:34 -0500, Michael E Brown wrote:
> > > On Mon, Jul 02, 2007 at 01:56:38AM -0400, seth vidal wrote:
> > > > Hi folks,
> > > >  I was working on some changes to download and save the mirrorlists to a
> > > > file in each repo dir so we can draw from there instead of always having
> > > > to hit the network, like with -C or with a user-call. Anwyay - I was
> > > > wondering what people thought we should use as enough time to avoid
> > > > hitting the mirror? Is the metadata_expire time a reasonable default to
> > > > use for the mirrorlist, too or should we define another config option
> > > > for mirrorlist expiration?
> > > > 
> > > > welcome to hear preferences.
> > > 
> > > I can see two approaches:
> > > 
> > >   1) Use the http status codes to handle cache control. ie. I can add an
> > >   expires: header to my output, and you could honor that. If no expiry
> > >   header is given, default to a reasonable value (1 week?)
> > 
> > not all mirrors are http nor all mirrorlists.
> 
> 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.

-sv





More information about the Yum-devel mailing list