Upgrading can be simple

Upgrading software from sources can be very simple, but there are several precautions you should take, especially if you're new to compiling from sources, or if you're not very familiar with the particular source archive you are installing. The top things to watch out for are listed below, but in most cases, an update is almost identical to the original compilation and install steps. That is, the steps include a tarball extraction, a possible "./configure", "make", and "make install". If these terms are not familiar to you, then check out developerWorks' tutorial on Compiling and installing software from sources, and then head back here.

Back to top

Read the Changelog

After downloading the sources, familiarize yourself with any new changes to the software -- normally, these changes are itemized in the ChangeLog or README file in the main source directory. You may find that configuration file settings have changed slightly, or that new features have been added. It's best to find out about these changes from the source documentation, rather than stumbling upon them later. Not doing so is definitely a bad move -- and besides, since you're taking the time to install a new version of this particular software package, wouldn't it be a good thing to know what new features or bug fixes are included?

Back to top

Upgrading critical applications

If you're upgrading an application that many users rely on (like the Apache on your busy Web server), then it pays to be extremely careful. If possible, practice installing the new version of the sources on a non-production box, and write down all the steps you performed to get the new version up and running. That way, if you run into a problem during the upgrade, no harm is done. And, when you're ready to upgrade your production box, you'll have a careful list of steps to perform -- reducing precious downtime.

In addition, if you're upgrading a critical app, it's always best to do so during off-peak hours.

Back to top

Configure it the same way

One of the main mistakes that people make when upgrading an app is to specify different and incompatible options on the "./configure" line or to uncomment different lines in a configuration Makefile. If you want to perform a simple upgrade, make sure that the new version of the software is configured exactly like your current version was.

If your current version looks for its configuration files in /etc, it would be nice if the new version did too. Don't be sloppy; if you pass different options to the "./configure" command, you could easily end up with a new version that has significantly different functionality, installs into the wrong directory tree, or looks in the wrong place for its configuration or data files. If you can't remember the configure options or Makefile defines you used originally, make sure you find out before you compile and install the new sources. To make the upgrade go smoothly, you'll want to get these settings right from the start.

Back to top

Back up old config files before install

For many packages, the real challenge comes not in the compilation and installation stages, but in the process of setting up an application to work properly after you've typed "make install". This normally involves spending a few good hours editing an application's config file, which is normally found in /etc, sporting the popular ".conf" suffix.

When you install a new version of a package by typing "make install", most Makefiles won't overwrite your existing configuration files sitting on disk -- but it's always better to be safe than sorry. If you're not completely sure, by all means back up those precious config files! Depending on the package, some configuration files could take days to reconstruct. If they happen to contain encrypted passwords, reconstruction may be extremely time consuming or impossible.

If you're planning on making major upgrades to your Linux system, this may be a good time to perform a full system backup. It's an especially good idea if you're going to upgrade a critical system library or tool that many other packages depend on to function properly. Full system backups are good things in their own right, and I hope you back up your system on at least a semi-regular basis.

Back to top

Keep the older source handy

I don't mean to discourage you from upgrading to the latest version of your favorite program -- but it is possible that the new version simply won't work. Maybe "./configure" will bomb out, or maybe "make" will. Worst case scenario, maybe everything, including "make install", will go splendidly until you actually try to run the program. Buggy source releases do happen, and that's why it's a great idea to keep your older sources (and any installation steps) handy in case the newer sources aren't up to snuff.

Back to top

Test it!

It's one thing to compile and install something, and quite another thing to make sure that the new software actually works. You'll want to make sure that you didn't just install 500 KB worth of garbage onto your root partition. Maybe the new version's config file needs slight, or even heavy, tweaking. If you're updating a daemon, make sure your configuration scripts successfully start the new version on reboot. You definitely don't want to find any problems two weeks later, when you reboot your server (and the program's configuration details are not fresh in your mind). You can follow all the advice in this article, but if you don't test your setup, you're skipping the most important step.

Now, you should be adequately equipped to upgrade your favorite app. Have fun!

Resources

• Take Daniel Robbins' tutorial on compiling and installing software from sources on your Linux box, available exclusively on developerWorks.
  
  
• Take Daniel's tutorial on compiling your Linux kernel, another developerWorks exclusive!
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Upgrading can be simple
• Read the Changelog
• Upgrading critical applications
• Configure it the same way
• Back up old config files before install
• Keep the older source handy
• Test it!
• Resources
• About the author
• Comments