No update of repo description today?

Bill Crawford billcrawford1970 at gmail.com
Mon Dec 5 18:01:53 UTC 2005


Horst von Brand wrote:
> Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> [...]
>
>   
>> As seth suggests set metadata_expire=reasonable number of seconds   in
>> your development repo definitions (to effect just those repos) or in
>> your main yum.conf(to effect all repos).  The time based  metadata
>> caching is a new feature for the 2.4.1 yum in rawhide.  The default is
>> currently 8 hours, meaning yum won't attempt to refresh its metadata
>> for 8 hours after its last metadata refresh.
>>     
>
> This isn't too smart, IMHO. I tend to run yum around the time the data gets
> pushed to the mirrors, in this way if I come early I won't get updates for
> a day or so.
>
> What /really/ annoys me is when yum gets old metadata from a repository,
> I think it should look for some timestamp and compare with what it's got
> locally, and just try the next mirror if the metadata is stale.
>
> And since I'm in wish-mode anyway, why not adding an option to install what
> can be installed when there are broken dependencies? The data is certainly
> available... Yes, I do understand that indiscriminate use will lead to
> systems in which there are ancient packages blocking important updates, and
> nobody cares, but...
>   
 Soluble.

 Rename the primary.xml.gz to primary-<MD5SUM>.xml.gz

 Have the main repodata file point to that.

 Then, there's no way to download an older, stale version of the 
metadata (and to be clever, yum could cache a couple, so if mirrors get 
out of sync and you pick on older one when you go to install something 
ten minutes later, you wouldn't download a whole load of data that 
you've already pulled once).

 Obviously you still have the danger of try to d/l it before a mirror 
has finished syncing, but this way you could (hopefully) safely do a 
continued d/l of the tail of the file and know it should be valid.

 Even better, split the metadata up per package :D:D but that isn't 
going to happen. Alas.




More information about the fedora-test-list mailing list