instead, what I think would make more sense would be a modified repo architecture where the current repoinfo file is versioned, and there's a master file which refers to the name of the 'current' version. so, to update the repo, you first copy all the new packages, and the new versioned repoinfo file(s), then you atomically update the master file to point to the new one, then some standard interval like 24 hours later, you clean up the old stuff to do a yum update, you atomically read the master file once, and then read the versioned repoinfo etc and do your thing. you have to bring up this new 'versioned' structure of the repo metadata in parallel with the current structure, so existing yum clients continue to work as-is with the existing warts for the foreseeable future. note I wrote the above without refreshing my rather rusty and vague memory about the structure of a repo and its metadata.