On Sun, 2006-09-03 at 00:20, Panu Matilainen wrote: > >> > >> You can set the versionlock file to be somewhere remote, eg > >> locklist=http://my.main.server.com/versionlock/distro/$releasever or > >> similar. Then you just control that one file, all yum update/install > >> operations will use the versions specified there no matter what other > >> versions are available. > > > The scenario is that one machine > > is used for testing and once it is approved, the same set > > of packages should be updated on a group of remote machines > > in different locations. However, one or a few RPM packages will > > be local system config files that are tied to the machine > > location and should not be identical everywhere. > > On that testing box, once a given pkgset is approved, you generate the > versionlock list with something like 'rpm -qa > versionlock.list', edit if > necessary (eg to allow for those per-machine differences) it to the > published location all clients look at. That's how it basically goes. Thanks, I can arrange for the test system to commit the list into CVS and the others can grab a fresh copy though the web interface which will mesh nicely with the way we manage a lot of other files. A couple of other questions now: can I expect the versionlock to work 'backwards'? That is, if the testing turned out to be optimistic, could I back down to the previous packages by using the list from the prior CVS commit (assuming the repositories still held the old files, of course)? Also, regarding the local-difference package - so far these are named differently (sitename-config-nn.nn-nnxx.noarch.rpm, etc.). If we hand-install the right version in the first place, will the presence of a test-site package in the list be ignored during an 'update' operation and latest site-config package matching the installed one be pulled from the local repository? If that is the case, we wouldn't have to edit the list to correspond to the sites. > >> One way to do "download only" with current yum itself is to set > >> tsflags=test in yum.conf, that way it'll just perform a transaction test > >> but not actually do anything to the system. Or you can write a five-line > >> plugin to make it stop once download completes. > > > > Again, how is someone supposed to know how to do this? Do you > > now have to know python to interact with yum beyond the default > > 'I hope the repository is OK' mode? > > As was pointed out by Seth, such a plugin has been already written while I > wasn't looking :) And it even seems to be in the fedora FC5 disto or extras, but not documented on the wiki or anywhere else I can find. It is an important option when you need to schedule the times that changes will be made with some degree of precision. -- Les Mikesell lesmikesell@xxxxxxxxx
