On Mon, 2006-09-04 at 14:37 -0500, Les Mikesell wrote: > 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)? Yum doesn't support downgrading so no, you can't go backwards. > 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. Not quite sure what you mean here, but the way versionlock works, it makes yum ignore every other version of a package mentioned in the list. Any package mentioned in the locklist that can't be found in the repositories will simply be ignored by it. So if you hand-install package mysite-config-1.2.3.noarch.rpm and it ends up in the versionlock list, if a package called mysite-config can't be found in any available repositories it'll have no effect at all. Better yet just filter out the package completely - packages not mentioned in the locklist will behave the usual "newest wins" way. Does that answer your question? - Panu -
