Do-It Yourself Computing 2: Packages

In Linux Land, distributions are often divided into categories based on how they manage software. It's more than just keeping track of what is installed, but what version. The obvious issue is security updates. Software is usually offered in packages. Sometimes they are all self-contained; often there are packages which depend on others. These dependencies usually make sense, but not always. You don't have to be a developer to know there is no sense in requiring one package with another, when the second won't even use the first. Yet I assure you it does happen. Sometimes it's a simple matter of adding extra packages to add extra functions. Either way, it helps if the package management is smart enough to tell you what it needs to run when there's something missing. There are three main systems for package management.

1. Debian and its derivatives use DEBs. You recognize them because the file names end in ".deb" which can be installed in several different ways. Debian's hallmark is breaking packages down into smaller chunks, so that almost nothing is self-contained in a single DEB.
2. RedHat and its friends use RPMs. This is an abbreviation for RedHat Package Manager. Both RPMs and DEBs are compressed software bundled with a set of instructions which inform the management system what it is, where it goes, and what has to come with it (dependencies). The original tool for managing these RPMs is the rpm command, invoked always with switches to indicate what you want it to do.
3. Some packages are simply zipped up bundles, and have to be installed manually. They are usually marked with ".tgz" or some variation. Of course, if you are downloading source code to compile yourself, they also usually come with that on the end of the file name. Lately a slightly different zip format has become popular, which ends in ".bz2" -- both this and the tgz format will be covered more in-depth in another lesson.

Obviously, we are concerned here with the second package format. As noted, you can handle these from the commandline using the rpm command, and if you are missing a dependency, it will complain and not install. Usually the complaint ("error") will specifically indicate the names of other RPMs it will need. Of course, each of those may also require something else, and the confusion possible is referred to as "cascading dependencies." Debian avoids that by using something called apt and there is a version for working with RPMs. However, those using RedHat and such tend to prefer yum: the Yellowdog Updater Modified. You can run a search on Yellowdog Linux to find out where that comes from, but the point is yum is about the most intelligent way to manage RPMs. In a terminal emulator (or "console window"), you can run the command man to review the manual page for yum:

man yum

This displays a manual page describing something about how to use yum. Most manual pages ("manpages") can be found by typing man followed by the command you need to know about. They tend to be rather terse and written for those already technically adept. Honestly, there's nothing wrong with reading the same manpage repeatedly, because eventually your mind will begin to make sense of the jargon. However, the hardest part is sometimes just knowing the name of the command for something you want to do. Cultivate a good rapport with those who are somewhere up the road ahead of you in learning Open Source, and you'll learn a lot more. Even if their answer is a brief "man command," you'll at least know what you are hunting.

The yum package manager is installed by default on CentOS. When you have your Internet connection up and working, in the console window type yum update. What you are asking is to have all your currently installed packages updated to the latest version offered for this release of CentOS. If you watch the output on the screen, you'll proabably be amused to notice some are tagged "CentOS" and many are variations of "rh4". In general, only those packages modified by the CentOS team are so named; almost everything else comes straight from RedHat without any changes, and simply compiled and packaged by CentOS. What happens is yum will connect to the default server for CentOS packages and compare what you have with what is available. To do that, it will also download a list of package descriptions, called "headers." Then it will list for you what it needs to download to comply with your request, along with some statistics about the transaction. It will wait for you to hit y for "yes"; or n for "no." For the most part, this is all about getting security and bug fixes, and possibly simple enhancements. The best part is, yum seldom fails to figure out all the dependencies for you, and automatically includes them.

Of course, we note CentOS doesn't always have everything you might want. For example, you might want the latest and best version of MPlayer, which can play MP3s, Windows Media files, Quicktime movies, etc. Do you have to build it yourself? You could, but it's not necessary. You see, there are folks out there with lots of skill and expertise who build these specialized packages and offer them to CentOS users. They often coordinate closely with the managers of CentOS (and RedHat) to insure consistent quality. Indeed, the CentOS website will mention one for you, with a link. If you follow that link, you'll find yourself at a website run by someone called Dag. I highly recommend you read Dag's Frequently Asked Questions (FAQ). For example, this question and those immediately following will help you learn how to make changes to some configuration files so that yum will automatically check Dag's collection of packages for later and/or better versions of what you have installed.

You can also use yum to add new packages, such as the previously mentioned MPlayer. Once you have the Dag repository listed on your system, you can simply command yum to add MPlayer and some dependencies:

yum install mplayer

You can watch as yum gets the package headers from Dag, runs down the list of dependencies, and summarizes the list of packages it will fetch, how big they are, etc. Hit y and watch it work. If you want MPlayer to work as a plugin for Mozilla, simply ask for the plugin first, and the other stuff will be included:

yum install mplayerplug-in

You can visit this page for a list of package names and links to versions available and what they do. If you read the page on mplayer you'll see mention of a directory which the package will create named win32, but not much explanation why. If you try MPlayer as it is on say, a Quicktime movie, you'll get sound but no picture. That's because there are some "codecs" missing. Most package makers are reluctant to offer this as a package, over concerns of copyrights and such. However, you can check your search engine for "mplayer codecs" to get the full story. You can also find a link to the download page where you can get the entire set of codecs available (hint: the "all" package).

You'll get a .tar.bz2 file. Move this into an empty directory. I prefer /usr/local/src. There, you will first unzip the package:

bunzip2 all-20050412.tar.bz2

This will decompress the file and change its name, removing the .bz2 part. Then you have to break down the bundle, called a "tar file":

tar -xvf all-20050412.tar

If you read the tar manpage, you'll see the flags tell tar to extract the archive (bundle of files), to give you lots of feeback on the process, and that the file we are working on is named following the command. This time the tar file will still be there, but you should have a directory with a similar name. On most Linux consoles and terminal windows, directories are highlighted in blue letters when you run the list (ls) command. If you move into that directory (using the cd command) and type ls again, you'll get a long list of files with names you couldn't imagine. All of these need to be moved into that win32 directory, which happens to be at /usr/lib/win32. The simplest way is to use the move (mv) command from the commandline:

mv ./* /usr/lib/win32/

What we did was tell mv to take all the files (*) in the current directory (./) and move them to the other place. Now when you open MPlayer, all those various codecs are in the right place, and you can see and hear most media files commonly found on the Internet, and quite a few not so common. When Mozilla encounters one of these files, it should open it automatically in the browser window.

Ed Hurst is Associate Editor of Open for Business. Ed runs a computer support ministry in Oklahoma City. He loves computers, runs FreeBSD and GNU/Linux and reads all sorts of things. You can reach Ed at ehurst@ofb.biz.