|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Wednesday, 7 June 2000||Author: Quentin Cregan|
|Published to: learn_articles_firststep/General||Page: 1/1 - [Printable]|
An Introduction to Packages and the RPM System
So, you've just moved to Linux, and now you're wondering how to install software, and what these "packages" are. This article will introduce you to packages -- specifically, packages in the popular RPM format used in distributions including Red Hat, Mandrake, SuSE, and Caldera.
|Page 1 of 1|
So, you've just moved to Linux, and now you're wondering how to install software, and what these "packages" are. This article will introduce you to packages -- specifically, packages in the popular RPM format used in distributions including Red Hat, Mandrake, SuSE, and Caldera. Future updates will encompass the DEB format used in Debian distributions, upcoming package formats, and more.
What is a Package?
First off, let's talk about what makes a package. A package is simply an archive of files, usually an application or set of applications for your system, similar to ZIP files in the DOS and Windows environment. However, packages are designed to work with a certain packaging system. So, you could think of them as slightly more intelligent ZIP files. For example, they know what other programs are required before they can be installed, and they make sure these "dependencies" are met before they will let you install them. They also have the good grace not to let you install them if that would break another piece of software that's already installed. So they're polite, too.
Generally speaking, packages contain pre-compiled, or "binary" software -- in other words, software that is ready to run on your system. Someone on a computer somewhere has already spent the time turning it from source code into an executable file. This is the joy of packages! Rather than taking lots of time to download and compile (that is, convert the source code you just downloaded into a binary file your system can run directly) the latest and greatest version of XFree86 4.0 or some other program, you can use a copy that has already been prepared by someone else. This saves time in compilation, saves time downloading (as binaries are generally far smaller than the source code) and lessens administrative load.
When source code is compiled, the way that the binary is produced is dependent on a number of things. A major factor is the type of processor the machine is using. Examples of processor types include: Intel/x86, used in PCs; Sun Sparc, used in Sun Microsystems' Unix workstations; Digital/Compaq Alpha, used in Compaq's Unix workstations; and Apple/Motorola PowerPC, used in Macintosh systems. Also important are the system libraries that this person had on their system during the install. A system library is just like a real library; it's a set of references which show an application how to do things, such as show your e-mail program how to use the Internet. If the person who prepared your package uses references that aren't the same, the package may not install on your computer properly.
Now, a word on package names. You may wonder what the differences are between RPMs, DEBs, SRPMs, and so on. RPM files are Red Hat Package Management files. This means that they use a packaging standard that was originally developed for the Red Hat Linux distribution. Other distributions have decided to use RPM, such as SuSE Linux. DEBs are Debian package format files, for Debian. Once again, this packaging standard has been picked up by other Debian-based distributions such as Corel. Both of these standards do things a little differently, so there is some argument as to which is the better package management tool (which we won't go into now).
Linux supports multiple hardware architectures. What this means is that Linux can run on anything from a Sun workstation to a regular Intel x86 PC. This is important to note when downloading packages from slow, distant FTP servers in Kazakhstan. You don't want to download a package called "softwarepackage-95931.sparc.rpm" only to find out that your machine is in fact, a regular Intel Pentium-class machine, and you should have stuck with "softwarepackage-95931.i386.rpm" as the download. Now you have a lump of useless 0s and 1s taking up valuable space. Evict them and move on. "Sparc" in the filename or directory name often indicates that the package has been made specifically for a machine with a Sparc processor and will not work with anything else. "i386" means normal PC clone workstations -- Intels, AMDs, Cyrixs and the like. "Noarch" tends to be more for scripts and documentation packages which could be used on any of these systems. Other names that may crop up often include "m68k," "alpha," and "ppc." The point is that you will need to be aware of these distinctions when downloading your packages.
Created by Red Hat, RPM is probably the most prolific package format. When installing a package, the rpm tool will update a central list of software that is installed on your system. This is to make sure that the same package is not installed twice, or that by installing this package you'd be "downgrading," and so on. Good places to pick up RPM package files include rpmfind.net, one of the world's largest archives of user and vendor-donated RPM packages. Alternatively, check Red Hat's "contrib" section, in the "/pub/redhat/libc6/i386/" directory of your nearest Red Hat mirror (such as ftp://download.sourceforge.net/pub/mirrors/redhat), or ftp://ftp.redhat.com/ itself.
So, let's see it in action! For example, say you've been wanting to try out the notice transport system called "zephyr." First, you've downloaded all the necessary files from Red Hat's contrib archive, or one of the other locations listed above. Specifically, you would have downloaded three files:
zephyr-2.0.4-9.i386.rpm zephyr-devel-2.0.4-9.i386.rpm zephyr-server-2.0.4-9.i386.rpm
Now, you want to install these. The following will give an example of some of the functions of the "rpm" program. Remember, these examples are just for demonstrative purposes. Let's say you try to install "zephyr-server" first.
root@titania:/home/q > rpm -iv zephyr-server-2.0.4-9.i386.rpm error: failed dependencies: zephyr is needed by zephyr-server-2.0.4-9 libzephyr.so.2 is needed by zephyr-server-2.0.4-9
It appears that we are having a "dependency" problem. This package just wants the other software to be installed first before it will work. So, let's check if installing the "zephyr" package will solve our woes:
root@titania:/home/q > rpm -qp --provides zephyr-2.0.4-9.i386.rpm libzephyr.so.2
Well, it provides the missing library. And since the package name itself is "zephyr," we can be fairly safe in assuming that "zephyr" will be provided too. Now, the "-qp --provides" arguments to RPM told it to go into query mode ("-q"), to query an uninstalled package file ("p"), and to list what it provides ("--provides"). A list of more functions is available by typing "rpm --help | less" or simply "man rpm".
So, we go ahead and install it:
root@titania:/home/q > rpm -Uvh zephyr-2.0.4-9.i386.rpm zephyr ##################################################
Ok, it's installed! Note my use of "-Uvh" as my argument to rpm. This told it to Update/install a package, be verbose about it (give detailed information on what it is doing), and print hash marks as a progress meter. If zephyr had been installed already, the use of "-U" would give rpm the ability to merely update the package from an earlier version.
Now, what did it install? Let's check the actual file changes:
root@titania:/home/q > rpm -ql zephyr /etc/rc.d/init.d/zephyrd.init /etc/rc.d/init.d/zhm.init /etc/rc.d/rc0.d/K09zhm ...and so on.
We just asked rpm to view its central list of packages we mentioned earler, and to tell us what files it knows of that belong to this zephyr package. It has returned these as a long list which can be perused later.
So, can we now install zephyr-server? Of course we can! We've just installed the program that zephyr-server wanted to see before it itself would be installed. Let's try it now.
root@titania:/home/q > rpm -Uvh zephyr-server-2.0.4-9.i386.rpm zephyr-server ##################################################
This now installs quite happily. The hash marks are similar to a progress counter heading across the screen as the package installs. Now, if you've made a mistake, and want to get rid of the server, this is generally no hassle with packages. Here's how it's done:
root@titania:/home/q > rpm -e zephyr-server
Done. Really! Want proof? We'll type it again:
root@titania:/home/q > rpm -e zephyr-server error: package zephyr-server is not installed
Now, let me warn you of a bad habit that you don't want to develop. Say you had yourself compiled, for example, the zephyr client without bothering to inform rpm that this had been done. You'd have a hard time convincing it to let you install zephyr-server. It might say "missing required dependencies," even though you know they're present. This is fairly easy to overcome, but it may lead to software not working correctly if you actually haven't got the prerequisite packages installed. Try "rpm -Uvh --nodeps filename.rpm" and it will happily install whatever you've asked it to, without complaint. However, this can lead to big trouble later, so only use it when you know what you're doing.
Of course, no $.50 AUD tour would be complete without a quick way to check on what a particular package is. This is achieved by the use of "rpm -qpi" for uninstalled packages, or "rpm -qi" for installed packages. For example:
root@titania:/home/q > rpm -qpi zephyr-2.0.4-9.i386.rpm
Relocations: (not relocatable)
Build Date: Wed Jul 15 23:45:18 1998
Install date: (not installed)
Build Host: passy.polytechnique.fr
Source RPM: zephyr-2.0.4-9.src.rpm
Packager: Elliot Lee
We hope this article has given you a brief crash course on what package files are, and how you can use them from the command line. You may end up using "prettier" graphical tools such as SuSE's YaST2 and Red Hat's gnorpm tool, but you now have a good background from which to use them. The next article in this series will discuss Debian's DEB packages, in similar depth. Until then, have fun with your newfound package installation skills!
|Page 1 of 1|