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: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
