Versioned or even host specific repositories are not that hard (so to speak).
You need 3 or 4 or 5 things. 1) A big fat ugly collect everything under the sun repo...the BFR for short. 2) Some modicum of control over the machines to be updated.. say type1, type2, type3 3) A group of test machines that are representative of type[1-3] 4) Some scripting and database skills. 5) Lots of political clout.
So pick your favorite method (rsync, curl, wget, carrier pigeon) for populating the BFR and let er rip.
As part of defining your types, create a complete list of the names of the rpms (including the versions) that is installed or that is ok to install for this type. Place this list under version control (cvs, subversion or maybe git...). Create a script to read the list, and create a link farm pointing into the BFR. Run createrepo on this link farm and give it a meaningful name (type1-versiony maybe).
As part of the install process create a record (database, ldap, flat file, stone hieroglyphics) containing the hostname, the type and the version of the rpm list (actually the repo version).
Wait a few days for new stuff to trickle or gush into the BFR and for your customers to find out that their stuff is out of date, or included in a CSIRT, or that version latest is absolutely required to be able to implement company saving project z on time and bombard your manage..never mind.
Take one of your test machines, and build the type(s) that could be effected at their original revision level. Create a new repo list with the new version of the rpms. Test with all of your automated test harness (covered elsewhere :-) ). Pronounce it good (preferrably after a multiple of 6 time periods) and commit it to your version control system and create a record saying that typex is now at version y.
Perform the requisite sacrifices and rituals to get the change controls in place for some, all or one of the typex machines. While waiting for the change control approval, repeat the test and creation phase at least twice, or as often as time allows. (Having something to do will keep you out of trouble.)
Now use your remote management tools (cfengine, Tivoli, ssh, whatever) to invoke yum with something like yum -c http://updateserver.lan/yum.php?host=fred&type=type1 -y update
Oh I forgot to mention that you need to create a php,perl,cgi script to look up the host name and or the type and return an appropriate yum.conf. This script can do many interesting things, like forcing all typex's to be at rev k, or only hosts that match regex j and type d, or even allowing certain hosts to have direct access to the entire BFR, etc, etc, etc....
there, that didn't hurt much.....
Of course you can go as deep as you want here. You could probably tie the change control system together with the management tools and the testing tools and a Kerberos ticket server if you really wanted to control stuff. And you could wrap the yum invocation with a check of what is installed against what is supposed to be installed, backup config files, etc, etc, etc. But I digress.
------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine