NAME - Script to assist you in hand made RedHat upgrades

SYNOPSIS [-v] [-ud] [-ubh] [-o oldpkglist] newpkglist

 -v          Print verbose/debug info
 -ud         Use the 'Distribution' field to help detect RedHat packages
 -ubh        Use the 'Build Host' field to help detect RedHat packages
 oldpkglist  List of packages available for the RH version 
             that is currently installed on your machine.
 newpkglist  List of packages available for the RH version 
             you wish to upgrade to

 --version   Prints version and date, and exits
 -h/--help   Prints this help screen and exits


This program generates a list of files that help you choose which packages in newpkglist you want to upgrade or install (by comparing the new list to the packages you currently have, and the packages in the old list, if supplied)

In order to find out whether an installed package is from RedHat, or if it's a ``contrib'' package, by default the 'Vendor' field checked. Unfortunately, some upgrade packages (at least for 4.2) do not contain the vendor information (they were either done too fast, while responding quickly to a security problem in some package, or they may have been made by a newly hired rookie :-D)).

Therefore, if you find out that some official RedHat packages end up being detected as contrib packages, try -ud to look for ``Red Hat Linux'' in the distribution field (This is only moderately effective because some RH 4.2 packages do not carry that information, and newer RH releases don't mention 'RHL' in the distribution field (5.0 just says Hurricane)). This is why you can use -ubh which will look for a build host in the domain (this seems to catch everything, but if someone makes contrib packages on a, they will be mistaken for official RedHat packages).

oldpkglist and newpkglist are both expected to have one package name per line (with their full name). The list should look like this:

One way to make the newpkglist file is by doing something like this:
 (open ftp session to site that has the RPMS packages of the new distrib)
 (cd to RPMS directory)
 ftp> ls . /tmp/tmppkglist
 output to local-file: /tmp/tmppkglist? y
 200 PORT command successful.
 150 Opening ASCII mode data connection for /bin/ls.
 226 Transfer complete.
 ftp> 221 Goodbye.
 moremagic:$ cat /tmp/tmppkglist | cut -c55- > /tmp/pkglist

Once you have the list, keep in mind that the script has to be run on the machine you intend to upgrade (because it launches an ``rpm -qa'' to find out which packages you are currently using)

 A redhat package looks like this:

The package version number is assigned by the author of the program, whereas the redhat release number is typically the number of times the package had bugs or configuration problems removed.

If the input file is pkglist, the following files will be created (in the same directory than where pkglist is):

Note that all the output is meant to be parsed by scripts, so lines are not broken (even if they don't fit on a 80 column terminal). Likewise, all the files list one package per line, with the exception of pkglist.contribclash which looks like this:

 You have: bash-2.0-1, and the new list has: bash-1.14.7-1.i386.rpm
 You have: lynx-2.7.1-1, and the new list has: lynx-2.6-2.i386.rpm
 You have: zgv-2.7patched-1, and the new list has: zgv-2.7-5.i386.rpm 

I expect that you know how to generate a script that would launch a bunch of rpm -Uvh ftp://path/file.rpm from one or several of the generated lists. If you don't, then you probably shouldn't use rhupgrade as it might introduce some subtle problems that you may have a hard time fixing.

Note that it is actually a better idea to download the packages you intend to update first, and then run rpm on them. The reason is that some packages depend on other ones and you will eventually try to upgrade a package that depends on one you don't have. This will cause the upgrade to fail, and you'll have to download the packages again, until you get all the dependencies right.

If I didn't scare you off from using this program yet, here are an few examples of things that can happen:

I did a partial upgrade of RH 4.1 to 4.2 with the help of this program. I upgraded pam, and one of its changes was to replace /etc/pam.conf by /etc/pam.d/ and one file for each pam aware program. This turned out to break su, as it is bundled with sh-utils and that su would not find any valid line in the recently emptied /etc/pam.conf. I had to upgrade sh-utils to get a new version of su that had a /etc/pam.d/su file.

This is however nothing compared to what can potentially happen to you if you do a partial upgrade to RH 5.0. For instance, if upgrade to glibc, but don't upgrade SysVinit, your system will not boot because you would have an /sbin/init linked against libc5, and unless don't have a /usr partition, init won't be able to find, and your system won't boot (unless you specify init=/bin/sh on the lilo prompt). Oh, and did I mention the package containing kerneld was renamed from modules to modutils, so if you don't look at the list of new packages, and install this one, possibly along with a few other ones, you may have some problems when booting later.

You can find more tips on upgrading from RH 4.x to 5.0 later in this document

Anyway, the important thing to remember is that if you do partial upgrades, use your brain and don't go to RH or me crying for help if everything breaks :-)

NOTE: You should not have to, but if you really want to be on the safe side, you may want to switch to single user while doing the upgrade of certain packages, or kill some specific daemons (crond comes to mind) while they are being upgraded (some programs could get confused if they are upgraded while they are running)


Why did I write this program?

I had rather painful upgrade from RH 3.0.3 to RH 4.0 because I had a heavily customed system, and fixing everything from the very limited root shell you have during the floppy upgrade was not fun.

This program was written to facilitate upgrades ``by hand'' grabbing just the packages you need, and using command-line RPM to upgrade the packages you want to upgrade (all this on a live system, without rebooting).

Why would you want to use it?


As you most likely know, RH 5.0 uses the new glibc library. For those who remember the a.out -> elf switch, it's not as bad as there is some degree of compatibility between the two (namely some libc5 binaries will run with libc6/glibc shared libaries), but you'll more or less have to upgrade everything anyway.

You should know that upgrading to 5.0 by hand is not trivial, but if you decide to go ahead, here are some tips:


The three users that I know of haven't complained yet, so you tell me :-D

More seriously, those lists are for informative use only, this script should not be a substitute for your own good jugement, but it's proven to be very useful for me.

This script also expects that information in RPMs is accurate, and if not, the results are undefined. However, there is a workaround for packages from RedHat that don't have the Vendor field filled correctly: try the -ud and -ubh flags.

Note also that this script expects that the new list actually is from a distribution more recent that your current one, and the old list (if specified). If by any chance the new list has older packages that the ones you have (like running against the 4.2 list of packages when you have 4.2 + upgraded packages from the redhat site), the script won't know about it, and will list old packages as packages you should upgrade to.

As a last test, a simple regression test would be to do something like this:

 moremagic:$  wc -l pkglist.*
       3 pkglist.contribclash
     165 pkglist.notinstalled
       1 pkglist.notrpm
       3 pkglist.release
     243 pkglist.same
      13 pkglist.version
     483 total
 moremagic:$  wc -l pkglist
     483 pkglist 

(Now you know why some files have a '.' as a separator, and the other ones have a '_' :-D)


Marc Merlin

I won't old my breath, but if you use this script, I'd appreciate a little Email, just to make sure that I'm not releasing this, and writing all this documentation for nothing :-D