On 5/11/2012 11:34 AM, Les Mikesell wrote: > On Fri, May 11, 2012 at 11:49 AM, Warren Young<warren at etr-usa.com> wrote: > >>> If you've included a few programs from EPEL (etc.), do you mirror >>> that too? >> >> Who mentioned mirroring? > > How else can you be sure you have all packages needed for some > arbitrary mix of installations? If your trusted repo doesn't have all the packages needed, the system you tested on does not match the installed systems, hence you have no good test. If you have multiple system configurations, you need to test once on each system configuration. At that point, you will have all the packages you need to upgrade their peers. You might need one repo per system configuration, if the difference between them is great enough. But the number of such repos needed cannot be large, else you cannot be testing properly. For this whole scheme to work, you have to be able to one test machine for each stable machine, and say, "These two boxes have the same RPM set." >> A local repo is just a copy of a set of packages that does what you >> want. It doesn't necessarily have to have everything available in all >> repos you pull from. > > So the same person has to do the installs of of the all the machines? > Or coordinate with a group? That seems somewhat unreasonable. No. There is no more coupling here than between you and Red Hat. The private repo is a decoupling mechanism. The person updating the private repository does not have to be the one who uses it. >> If you think you want the freedom to install random things in an ad hoc >> fashion, that kind of goes against the idea of a tested repo. > > I don't want my own tested repos containing the same packages that are > available in the distribution. I want to be able to tell yum to > reproduce the package list/versions that are on the tested system. It > knows where to get them. Isn't it overkill to keep a whole repo > snapshot copy when you really just need a way to tell yum the package > versions you want on the 2nd box? Why all the agida? This isn't difficult: Step 0, done only once: set up yum repo, and modify the "stable" clients to use it: http://fedoranews.org/contributors/tony_smith/yum/ Leave the test machines pointing at the official yum repos. But, enable the "keepcache" setting in their yum.conf. Step 1: When each test machine is deemed stable after a yum update, rsync its /var/cache/yum/updates/packages tree into the yum repo. Step 2: yum-arch the updated repo Step 3: yum update the dependent machines. You can substitute cron discipline for Step 3, so that the yum updates always happen while the repo isn't being changed. That's it. Some minor setup, then three (or two) easy steps per update.