Managing rpms

[Robert G. Brown]

On Sun, 4 Feb 2001, Jon Tegner wrote:

> In a post awhile back the yup-package for maintaining rpms was
> mentioned, and I was wondering if someone has experiences of that or
> some other package which automatically takes care of updating rpms in a
> system (on the page http://www.rpm.org/software.html there seems to be
> several canditates).
>
> Regards,
>
> /jon

I've just started using yup personally, as it is being prototyped as a
method for automating the generally incredibly painful process of
keeping a system or set of systems both consistent and secure (in the
sense of being up to date with respect to security patches and the
like).

yup does a lot of things for an RPM-based distribution that we are used
to seeing only from e.g. Debian -- it is dependency aware and can update
an entire dependency tree with one call.  It also does sanity checks and
effectively forces one to eliminate inconsistencies from an RPM tree
before it will run -- on one of my oldest systems, I had multiple rpm
revisions of some packages installed which had survived the 6.2 upgrade.
yup patiently went through this and helped me figure out what was
bollixed up and remove or hand update things until it was satisfied that
the distribution itself on the system was at least not overtly broken
somewhere.

It can also be used to generate a plain list of all installed packages.

In application, once one has a clean system it becomes a simple
client-side call.  It can be run nightly in a cron script, for example,
on all clients.  The clients are directed to an FTP server which has yup
configuration information and distribution/update directories.
Everything is then done automagically -- it compares what you have to
what you should have, retrieves and caches copies of rpm's that need
updating and all their dependencies, installs them, removes the cache
copies, and goes away.

It can also be run from the command line targeted at specific packages.
For example, on the aforementioned host I still have a bug that is
preventing a full update (a bug which might well be in yup -- the
package isn't yet perfect).  However, it still works fine for individual
packages, and I'm working my way through "important" packages one at a
time.  Below is a trace of operation for updating e.g. lpr (which is
actually not that important on this host, but is out of date):

rgb at rgb|T:3#more /tmp/rpm-list
rgb at rgb|T:4#yup update lpr
Reading RPM database... (100%)
Performing dependencies sanity check...
Checking for package list updates...
Done transfering...    280B in   0.0s at  115kB per/sec
Package list is up to date...
Reading package list... (100%)

As requested, I will do the following:
[update: lpr]
Downloading lpr-0.50-7.6.x.i386.rpm
Done transfering...  89.6kB in   2.0s at 44.8kB per/sec
Reading packages... Done
lpr-0.50-7.6.x.i386.rpm [..........]
42.770user 0.780sys 86.8%, 0ib 0ob 0tx 0da 0to 0swp 0:50.16

This appears to be a bit easier than:

  a) Figuring out the package of lpr that I have.
  b) Finding out if it is superceded by an update
  c) Hand-ftp'ing the update rpm (and dependencies, if any) from a
     Red Hat mirror.
  d) installing the rpm(s) by hand.

One call, all automated.  If run a second time, it returns:

rgb at rgb|T:5#yup update lpr
Reading RPM database... (100%)
Performing dependencies sanity check...
Checking for package list updates...
Done transfering...    280B in   0.0s at  114kB per/sec
Package list is up to date...
Reading package list... (100%)

Error: Package lpr is already installed and is the latest version
40.620user 0.650sys 99.6%, 0ib 0ob 0tx 0da 0to 0swp 0:41.41

That's all I know at the moment from a user perspective (somebody else
is managing the FTP site and master yup configuration).  I believe that
this configuration process isn't too arduous, though.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu