On Fri, 2005-28-10 at 15:50 -0400, seth vidal wrote: > but then you still have to fetch and store the repomd.xml, somewhere > while you figure out if the current one is okay > just an arse pain. No, that's two different arsepains the way I see it. I envison it like this: Initial run: 1. Yum sees there is no repomd.xml in cache, and gets it. 2. Yum stores the "last-obtained" timestamp for that repomd.xml Consecutive run within cookie lifetime: 1. Yum sees there is a cached repomd.xml and checks the last-obtained. 2. Last-obtained is within the cookie liftime. 3. Yum doesn't re-fetch repomd.xml and proceeds with cached ones. The trouble here, of course, is that there is always a chance that the repository has been updated while we still hold on to the old data. This is the arse-pain #1. Consecutive run past cookie expiration: 1. Yum sees there is a cached repomd.xml and checks the last-obtained. 2. Cookie expired, so yum fetches the repomd.xml again. 3. If mirrorlists are used, yum compares "last-build" to the cached value, and, say, cycles the mirrors until it finds a last-build that is >= cached "last-build". There probably should be a sane limit here, like 10 attempts, after which the 10th mirror will be used to minimize user annoyance. The behaviour here is up for debate, of course. This is the arse-pain #2. How's that? --icon
