I subscribe to "Kevin's RedHat Uber Distribution (KRUD), which is a repackaging of Red Hat. Because I maintain five Linux machines of my own, this makes the upgrading and updating almost painless. The latest and greatest KRUD comes out once a month, and has all the latest versions and bugfixes. In addition, it has many packages not included in the Red Hat distribution.
In order to save myself a lot of grief, I keep two bootable partitions on my machines. When it is time to make a major upgrade, e.g. from 7.2 to 7.3, I clean off the unused partition, and then copy the current root partition to it, adjusting its mount points, fstab, and lilo.conf. Then I revise the active lilo.conf to reflect the new configuration and run "lilo". Then I boot to the new, duplicate partition to verify that it's set up properly, then I upgrade that partition. That way, if the upgrade process goes awry, I still have an operational partition to use until I have time to fix things. See my detailed instructions on how to do that.
You can try the GUI route if you like. It's the default at the boot: prompt. It will probably work if your video card and monitor have some age on them in terms of the leading edge. The GUI, however, has no functional advantage over text mode. It's just nice eye candy. If the GUI method locks up on you, try again with text mode (enter "text" at the boot: prompt). Note that this has nothing to do with, and has no effect on what kind of login screen you use (runlevel 3 - text, or runlevel 5 - GUI).
If your upgrade hangs or crashes, check the log to see what the problem was. In versions 7.2 and earlier it is in /tmp/upgrade.log. In version 7.3 it was moved to /root. Note: paths are relative to the root of the filesystem being upgraded.
The new version of kdebase introduces a change in part of its directory structure. In the previous version, /usr/share/config/kdm was a directory containing a symlink. In the new version, it is a symlink. The upgrade process does not convert it and the install fails. The solution is to
rm -fr /usr/share/config/kdm
before the upgrade.
There is a similar problem with the htdig-web package. The old version has a directory /var/www/html/htdig/ that contains a number of files. In the new version, /var/www/html/htdig is a symlink to /usr/share/htdig/ which contains those files which are part of htdig. The upgrade fails because cpio cannot replace the directory with a symlink. The solution is to
rm -fr /var/www/html/htdig
before the upgrade.
The 7.3 installer has shown itself to be not terribly robust when handling ext3 (journaling) filesystems. Convert your root (/) partition (and /boot, if applicable) to ext2 before upgrading. You can convert back to ext3 after the upgrade.
On a number of systems, particularly Athlon-based systems with VIA motherboards (I think), it has been necessary to add "noapic" and/or "nodma" options on the boot: command line. My three workstations are all AMD machines, one Athlon and two K6-3 machines. Only one of the K6-3 machines required those options to complete the upgrade.
Two of my machines had fairly old /etc/XF65Config files, and the X server did not like some of the keyboard-related items in there. On the machine that uses runlevel 5, I had to log in as root at a text screen, switch to runlevel 3 (telinit 3), run Xconfigurator, and then return it to runlevel 5. A pleasant surprise was that, on the machine with the 17-inch monitor, I was able to configure it for 1600x1200. Before, I had it configured for 1280x1024, the best I knew that it would do.
XEmacs has been kind of GUI-fied for some time, but GNU Emacs has been only "X-aware". Well, the new version of GNU Emacs now sports a GUI-fied toolbar. If you had shied away from it because of its complexity and arcane command set, you might want to reconsider.
The Sendmail in RH 8.0 is version 8.12.5. The big change with version 8.12 is the use of two daemons, one priveledged, and one unpriveledged. As a result, there are now also two configuration files, sendmail.cf and submit.cf, generated from sendmail.mc and submit.mc, respectively. IMHO, they did not adequately document what needs to go into submit.mc that used to go into sendmail.mc. I had to fiddle with it, on and off, for about a week to get it working adequately. It's still not doing 100% what I want. I'm considering switching to Postfix or Qmail. I'd jump in a minute, but I have two clients that still use Sendmail.
By the way, sendmail.cf (and submit.cf with it) has been moved to /etc/mail/.
First, the name of the RPM has been changed from apache to httpd. The version changes from 1.3 to 2.0. But, the significant change is that, instead of having all configuration in one monolithic file, /etc/httpd/conf/httpd.conf, now, only the basic httpd configuration is in that file. Anything involving things like mod_perl or php has been moved into separate configuration files in /etc/httpd/conf.d/, which are included from httpd.conf.
What that means is that your web server will not run, complaining that it sees a version 1.3 configuration file. The 2.0-style configuration file is provided in /etc/httpd/conf/httpd.conf.rpmnew. Fortunately, the changes are pretty simple, and you shouldn't have much trouble getting things up again.