Redhat Updates: Best Strategy?

[mbrodeur at NextTime.com (Matthew J. Brodeur)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 7 Dec 2001, Kent Borg wrote:

> On Fri, Dec 07, 2001 at 02:55:33PM -0500, Matthew J. Brodeur wrote:
> >    The command I would use to update a 7.2 system, given a complete
> > updates mirror, is:
> > [7.2/en/os/i386]# rpm -Fvh `ls *.rpm | egrep -v \
> >  '(^kernel-2.4.9|^glibc-2.2.4)'` ../i686/kernel-2.4.9-13.i686.rpm \
> > ../i686/glibc-2.2.4-19.i686.rpm ../noarch/*.rpm
> 
> 1. I am running Red Hat 7.0 with a bunch of previous updates,
>    including rpm 4.0.2.  Does that do anything to the parameters of
>    the egrep and the rest?  Or do I want all those same revs anyway?

   My fault for specifying a specific solution instead of a generic
algorithm.  _IF_ you're installing the 7.2 updates to a 7.0 system, which
should work, and it's an i686 class system, that exact command will work.  
Otherwise you'll need to adjust for your situation.  Essentially, that
command is run from the i386 directory and installs everything from there
_except_ those files that are available for a more appropriate arch.  In
the particular case of RH7.2 on an i686, the kernel and glibc are
available PPro optimized while everything else is i386 code.
   Each time I run an update I check for packages specific to my
architecture (i486/i586/i686/athlon) and egrep those out of the i386 rpm
list.  It's probably safer to specify the entire file name and escape dots
in the egrep, but I was being lazy.  You want to give it enough to
eliminate the files you'll pull from elsewhere, but still install the
associated packages (glibc-common, kernel-headers, etc).
   That last part catches the non-arch-specific packages such as fonts.


> 2. What if I have a boo-boo, how do I back out such an update?  Does
>    rpm have any snapshot feature?  Or do I just figure out how to fix
>    the results if something isn't happy?

   This really depends on what breaks and how bad it is.  If you just 
discover that a new package is broken in a way that the old one wasn't, 
you can reinstall the old package by rpm 'upgrading' (-U) to the old 
version (with -oldpackage).
   The most likely problem would be your configs getting clobbered by the 
new packages.  Although RPM usually will merge your customizations into 
the new file, or at least make a backup of your file, I sill make my own 
copies of any configs I've modified.
   What you're usually left with is either the new config installed where 
it belongs and your old file saved as file.rpmsave, or your old file will 
still be in place and the new file will be saved as file.rpmnew.  If that 
happens it's up to you to make your changes to the rpmnew file and install 
it properly.  This WILL happen if you RPM upgrade sendmail.  Samba and 
Apache come to mind in this category as well.


> 3. Why is rpm so opaque?  If I really suffer I can always dig what I
>    want out of the man page, but I want to get good it slinging it
>    around before I break something.  Is there a good document for it?
>    A decent cheatsheet?  Both??

   There is an old HOWTO at:
http://www.nexttime.com/LDP/HOWTO/RPM-HOWTO
   and this HOWTO mentions a book "Maximum RPM."  I think they're both 
outdated and I'll admit to not having read either.  I've been able to find 
what I needed so far in the man page.  I think the Red Hat manuals cover 
quite a bit about RPM as well.


- -- 
     -Matt

Batteries not included.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8ETUWc8/WFSz+GKMRAmD2AJoCcbyDk28a72G1Gn952LjnkFrl3wCeLW2Q
p4rdavxRO/ljXfia0fbc2tI=
=VkcR
-----END PGP SIGNATURE-----