Les,
I think this discussion has gotten lost in the weeds. What you want to
do is easy to accomplish using Yum, but you have to use Yum the way it
was intended to be used. First, you must have your own repository
server, which will host as many repositories as your change control
policies require (eg, untested, test, qa, production). Using the Centos
repositories directly means that you're rolling out on Centos' change-
control schedule, not yours. Set up your own repository and you can
control it.
The rest of this message is just a summary of things that others on this
list have already said.
1. You need your own repository server. This machine needs good
Internet connectivity, Apache, and about 100GB of disk space.
2. On your repository server, you need to host three repositories.
#1 is a copy of the Centos repositories you use, call it "untested"
#2 is a subset of #1, call it "qa"
#3 is a subset of #2, call it "production"
3. #1 gets updated nightly with a simple yum update. In other words, it
just copies the binary packages from the Centos repositories.
4. Keep in mind that #2 and #3 won't take up much disk space because the
files in these repositories are actually just links to the real files in
#1.
5. "createrepo" will create the Yum headers for all of the packages in a
given directory.
6. If you want to promote a set of packages from #1 to #2, you first add
links
(eg, "ln -s /var/spool/repo/untested/somepkg.rpm /var/spool/repo/qa/").
As you do this, any machine attempting to run "yum update" against the
qa repository will see no change.
7. Here's where the repo gets its atomicity: once all of the packages
are linked, you re-run createrepo. Until createrepo finishes, the repo
will appear unchanged.
8. All of your QA machines use your "qa" repository, and run yum update
nightly.
9. All of your production machines use your "production" repository and
run yum update nightly.
10. YOU control when createrepo is run on your QA and Production
repositories, thus controlling when things roll out.
