> > >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. :) /Brian/
