Indeed in my case I usually do something akin to .... yum --disablerepo="*" --enablerepo="myrepo" clean metadata yum -y upgrade --disablerepo="*" --enablerepo="myrepo" mypackage when updating custom rpms (or RPMs in a specific spacewalk channel) across systems. On 12 July 2010 15:12, Toralf Lund <toralf.lund at pgs.com> wrote: > James Hogarth wrote: >> On 12 July 2010 13:29, Benjamin Franz <jfranz at freerun.com> wrote: >> >>> On 07/12/2010 04:58 AM, Toralf Lund wrote: >>> >>>> So, it seems like I managed to correctly update the repodata and all, >>>> but originally, yum concluded that it didn't need to download a new >>>> version, but could use the one cached earlier. instead. >>>> >>>> Does anyone have any idea why this happened? How exactly does yum decide >>>> when to download new headers and when to reuse cached data? >>>> >>>> >>> You probably want the /etc/yum.conf file. There should be a line in it >>> right now that reads 'metadata_expire=1h'. >>> >>> >>> >> >> Rather than deleting that directory as a whole you would probably be >> better served by doing a yum clean metadata instead... >> > I suppose so. I though I might try removing only data for the repository > in question rather than clearing the entire cache when testing this, > though... > > - Toralf > > > This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >