On Wed, 2006-03-29 at 09:33 -0500, Brian Long wrote: > > > > > >Personally, I'd propose a different approach. While up-to-date > >versions do really matter when I am fetching security updates, they > >are typically less important when doing an "install". It could be > >configurable, how frequently yum updates its cached lists, depending > >on the operation. For example, I could configure "every time" for > >"update", and "two weeks" for "install". > > > > > This exists in some form in yum-2.4.2. The metadata is cached by > default for 2 hours, I believe. I just got bitten by this last night > while doing upgrade testing. We integrate yum into our RHEL 3 / 4 > releases for internally-controlled updates. Part of our yum-config RPMs > point to versioned repositories. For example, we have a version of > Cisco Enterprise Linux based on RHEL 3 Update 5 and another upcoming one > based on Update 7. We have yum-config RPMs which point to different > baseurl's depending on the release, but the repository names are the same. > > While testing our update wrapper (which points you from one versioned > release to the next), I found the metadata for the old version was being > cached. When I tried a "yum groupinstall", it was trying to used cached > metadata for the RPMs contained in the group and those RPMs didn't exist > because they had been updated out from under the cached data. :) > it's metadata_expire = it's set to 1800 seconds (30 minutes) by default and it is settable per-repo so you can set it to a low number on repos that frequently update and high numbers on repos that do not. -sv
