[Yum] Bleeding edge avoidence

[Les Mikesell]

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 at gmail.com