> I guess this is all quite similar to what Jon described for their 
> systems.

Sounds pretty similar to me, though our 'policy' re updates isn't quite so 
clean sounding and adding exceptions etc is all pretty much done by (my) 
hand here at the moment...

> Sorry, I have little to no experience with the yum plugins.

Because of the history of what systems we had here our first attempts to 
automate updates on rpm based Linux were based on concepts we had picked 
up over the years on Solaris, Tru64, Irix etc.

For a very long time we used a variety of custon (locally 
written/maintained) scripts to do the various rpm updates and ensure that 
our local config changes got put back after any updates.  With RH5,6,7,8 
and SL3,4 we also generated (nightly) our own install trees which included 
all 'current' updates as well as any additional local packages.

We carried on with this for probably too long with each os version 
requiring significant effort to tweak the various scripts.

The final straw was the SL4 changes took (me) sufficiently long that we 
missed our window to do a desktop rollout, and so I finally decided to 
consider using this 'yum' thing... :-)

Two things really appealed to me when I started looking at the options for 
using yum with SL5 (I don't know if they were true before as well):

   the anaconda installer could be simply pointed at any number of repos
   and so getting an install to get 'latest updates' plus our extra
   packages would be easy

   yum did proper dependency calculations - our old scripts had to have
   stuff like package-a replacing package-b coded into them (don't ask!)

I'd origianlly assumed that the 'right' way to use yum to impose policy 
decision would be to run it in test mode (e.g. check-update) parse the 
output and call it again with different options.

I would probably have done that if the yum authors hadn't chosen an output 
format which was not always useful (e.g. truncating strings to make them 
fit field widths etc).

So I was forced to consider writing a plugin and based on several of the 
examples I cobbled something together which pretty much does what we need. 
It doesn't do what we used to do, nor quite what we originally wanted but 
it is close enough for now.  It was my first piece of python btw so it 
isn't pretty nor probably using the normal idioms.

Some aspects of the yum/plugin apis are documented fairly well, others 
seem to be shrouded in mystery (to me).  e.g. I spent ages trying to find 
out why in some hooks one could remove packages from the set to be 
installed and not in others, only to find that I was actually doing it the 
wrong way in all places...

Existing plugins like installonlyn, changelog, skip-broken, and 
protectbase all were valuable sources of clues and examples of what can be 
done.  Someone who understands yum better than I do could probably do a 
much more complete job that what we curently have...

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/