On Fri, 15 Aug 2003, seth vidal wrote: > > > By 'should not be' I mean the set of packages-versions which are currently on > > the system that would be altered by running `yum -y update`. > > > > So package-1.2-3.rpm should not be on the system since package-1.2-4.rpm is available. > > > > Also netscape-4.7-3.rpm should not be on the system since > > say mozilla-5.0.rpm 'Obsoletes:' in the .spec file netscape <= 4.7-3. > > (Not a very good example I know but hopefully you get the idea.). > > I think I'm beginning to glom onto your meaning. > > So you're using the yum list updates to build a list of what needs to be > updated in order to push that to a db that then, I assume, pushes that > to an admin for the machine? > > Is that the goal? Thats sounds about correct. We have a large number of boxes about 1400 or so and there are problably 30-40 flavours of box within that. We are too scared to put `yum -y update` in a cron so wanted to be able to see an overview of the whole farm and catch the boxes which were missed of because someone was away or we just forgot about some weird service on the edge. Currently the web page display all the newer packages that are available to what is installed. Idealy displaying all the packages installed that could be replaced/upgraded would be better. This then allows us to priortise the patching sitation or delay an update that we feal is insignificant. I realise there is not a one to one mapping in an upgrade because two packages may obsolete one package. So having just the two lists from `yum update` and `yum outofdate` would be super. Steve > > -sv > -- Steve Traylen s.traylen@xxxxxxxx http://www.gridpp.ac.uk/
