497 lines
21 KiB
HTML
497 lines
21 KiB
HTML
<!--startcut ==============================================-->
|
|
<!-- *** BEGIN HTML header *** -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML><HEAD>
|
|
<title>Using RPM: The Basics (Part I) LG #68</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!-- *** END HTML header *** -->
|
|
|
|
<CENTER>
|
|
<A HREF="http://www.linuxgazette.com/">
|
|
<IMG ALT="LINUX GAZETTE" SRC="../gx/lglogo.png"
|
|
WIDTH="600" HEIGHT="124" border="0"></A>
|
|
<BR>
|
|
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="mitchell.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue68/nazario.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="nazario2.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
<P>
|
|
</CENTER>
|
|
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4 ALIGN="center">
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">Using RPM: The Basics (Part I)</font></H1>
|
|
<H4>By <a href="mailto:jose@cwru.edu">Jose Nazario</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<!-- END header -->
|
|
|
|
|
|
|
|
|
|
This documentation is designed to serve as a brief introduction to the
|
|
Red Hat Package Management system, or RPM. Part 1 will cover installation
|
|
of RPM packages, while part 2 will cover building your own RPM packages
|
|
for distribution. We will cover what RPM is, why you would want to use it,
|
|
compare it to other packaging systems on Linux and UNIX, and how to get
|
|
it. The bulk of the time will be spent on how to use RPM for installing,
|
|
checking packages, and removal of installed packages. Neither section will
|
|
cover the RPM API.
|
|
|
|
<h2> What is RPM?</h2>
|
|
|
|
The Red Hat Package Manager (RPM) is a toolset used to build and manage
|
|
software packages on UNIX systems. Distributed with the Red Hat Linux
|
|
distribution and its derivatives, RPM also works on any UNIX as it is open
|
|
source. However, finding RPM packages for other forms of UNIX, such as Solaris
|
|
or IRIX, may prove difficult.
|
|
|
|
<p>Package management is rather simple in its principles, though it can be
|
|
tricky in its implementations. Briefly, it means the managed installation
|
|
of software, managing installed software, and the removal of software
|
|
packages from a system in a simplified manner. RPM arose out of the needs
|
|
to do this effectively, and no other meaningful solution was available.
|
|
|
|
<p>RPM uses a proprietary file format, unlike some other UNIX software
|
|
package managers. This can be problematic if you find yourself needing to
|
|
extract one component from the package and you don't have the RPM utility
|
|
handy. Luckily a tool like Alien exists to convert from RPM to other
|
|
formats. It can be possible, through tools like Alien, to get to a file
|
|
format you can manage using, say, tar or ar.
|
|
|
|
<p>The naming scheme of RPM files is itself a standardized convention.
|
|
RPMs have the format (name)-(version)-(build).(platform).rpm. For example,
|
|
the name cat-2.4-7.i386.rpm would mean an RPM for the utility "cat"
|
|
version 2.4, build 7 for the x86. When the platform name is replaced by
|
|
"src", it's a source RPM.
|
|
|
|
<h2> Why Package Management?</h2>
|
|
|
|
At first glance you may say to yourself, "I can manage this myself. It's
|
|
not that many components ..." In fact, for something as small as, say,
|
|
cat, which has one executable and one man page, this may be so. But
|
|
consider, say, KDE, which has a mountain of components, dependencies, and
|
|
likes to stick them everywhere. Keeping track of it all would be tough, if
|
|
not impossible.
|
|
|
|
<p>Package management makes it all easier. By letting a program maintain
|
|
the information about the binaries, their configuration files, and
|
|
everything else about them, you can identify which ones are installed,
|
|
remove them easily or upgrade them readily, as well.
|
|
|
|
<p>Installation becomes a snap. You select what you want, and ask the
|
|
system to take care of the dirty work for you. Unpack the program, ensure
|
|
that there is space, place things in the right order, and set them up for
|
|
you. It's great, it's like having a valet take care of your car when you
|
|
go to a restaraunt. Dependencies, or additional requirements for a
|
|
software package, are also managed seamlessly by a good package manager.
|
|
|
|
<p>Management of installed packages is also greatly facilitated by a good
|
|
package management system. It keeps a full list of software installed,
|
|
which is useful to see if you have something installed. More importantly,
|
|
it makes upgrading a breeze. Lastly, this makes verification of a software
|
|
package quite easy to do. By knowing what packages are installed, and what
|
|
the properties of the components are, you can quickly diagnose a problem
|
|
and hopefully fix it quickly.
|
|
|
|
<h2> How Does RPM Compare to Other UNIX Package Systems?</h2>
|
|
|
|
I have had the (mis)fortune of working with many UNIX variants, and
|
|
gaining some experience with their package formats. While I sometimes slag
|
|
RPMs, in comparison to other UNIX software packaging formats I find it
|
|
usually comes out on top for my needs. Here's a brief rundown on the pro's
|
|
and cons of some of the other formats and tools:
|
|
|
|
<br>
|
|
|
|
<table> <tr> <td><b>Format</b></td>
|
|
|
|
<td><b>Platform</b></td>
|
|
|
|
<td><b>Pro</b></td>
|
|
|
|
<td><b>Con</b></td> </tr>
|
|
|
|
<tr> <td>inst</td>
|
|
|
|
<td>IRIX(SGI)</td>
|
|
|
|
<td>great graphical installer</td>
|
|
|
|
<td>amazingly slow, frequentl reboots after, no network installs (aside
|
|
from NFS)</td> </tr>
|
|
|
|
<tr> <td>sw</td>
|
|
|
|
<td>HPUX(HP)</td>
|
|
|
|
<td>(are there any?), also supports net installs</td>
|
|
|
|
<td>terribly slow</td> </tr>
|
|
|
|
<tr> <td>pkg</td>
|
|
|
|
<td>BSD(many) </td>
|
|
|
|
<td>tarballs, net installs</td>
|
|
|
|
<td>lack signatures, sums</td> </tr>
|
|
|
|
<tr> <td>?</td>
|
|
|
|
<td>Solaris(SUN)</td>
|
|
|
|
<td>(are there any?) </td>
|
|
|
|
<td>slow, lack signatures, sums</td> </tr>
|
|
|
|
<tr> <td>.deb</td>
|
|
|
|
<td>Debian</td>
|
|
|
|
<td>just ar's, easy to extract w/o tool </td>
|
|
|
|
<td>lacks signatures</td> </tr> </table>
|
|
|
|
<p>In brief, my biggest complaint about RPM is the lack of a solid GUI
|
|
interface to it. While a few exist (like gnorpm and glint), they lack the
|
|
more complex features that SGI's Software Manager has. Overall, I find
|
|
that RPM has better conflict handling and resolution than inst does, and
|
|
is much, much faster. Hence, i'm willing to live without a strong GUI.
|
|
|
|
<p>My biggest raves for RPM, however, are in speed and package checking,
|
|
using both package signatures and the sums of the components. As an
|
|
example, once I had to reboot an SGI just because I reinstalled the
|
|
default GUI text editor (aka jot). It also took approximately 15 minutes
|
|
to reinstall that small package, before the reboot.
|
|
|
|
<h2> RPM In a Nutshell</h2>
|
|
|
|
Much like a compressed tarball, RPM uses a combination of rolling together
|
|
multiple files into one archive and compression of this archive to build
|
|
the bulk of the RPM package. Furthermore, additional header information is
|
|
inserted. This includes pre- and post-installation scripts to prepare the
|
|
system for the new package, as well as information for the database that
|
|
RPM maintains. Dependencies are checked before any installation occurs,
|
|
and if the appropriate flags are set for the installation they are also
|
|
installed.
|
|
|
|
<p>It is this database that makes RPM work the magic that it does. Stored
|
|
in there are all of the properties of the installed packages. Should this
|
|
become corrupted, it can be rebuilt using the rpm tool.
|
|
|
|
<h2> The Hows of RPM</h2>
|
|
|
|
We will now focus on the three core actions of RPM discussed in this
|
|
documentation. They include installation of new packages, management of
|
|
installed packages, and package removal. We will begin at the beginning,
|
|
and how to add a package using RPM.
|
|
|
|
<h3> Installation Using RPM</h3>
|
|
|
|
This is the most basic RPM function, and one of the most popular: the
|
|
installation of new software packages using RPM. To do this, give rpm the
|
|
-i flag and point it to an RPM:
|
|
|
|
<p> rpm -i (package)
|
|
|
|
<p>This will install the package if all goes well and send you back to a
|
|
command prompt without any messages. Pretty boring, and worse if you want
|
|
to know what happened you're out of luck. Use the -v flag to turn on some
|
|
verbosity:
|
|
|
|
<p> rpm -iv (package)
|
|
|
|
<p>All that gets printed out is the package name, but no statistics on the
|
|
progress or what it did. You can get a hash marked output of the progress
|
|
is you use the -h flag. People seem to like using -ivh together to get a
|
|
"pretty" output:
|
|
|
|
<p> rpm -ivh (package)
|
|
|
|
<p>Again, this doesn't tell you much about what just happened, only that
|
|
it hopefully did. Hence, I usually crank up the verbosity (-vv) when I
|
|
install. This lets me see what's going on:
|
|
|
|
<p> rpm -ivv (package)
|
|
|
|
<p>While the output usually scrolls, I can see exactly what happened and
|
|
if any problems were encountered. Plus I get to see where stuff was
|
|
installed.
|
|
|
|
<p>Dependencies are handled pretty wisely by RPM, but this itself depends
|
|
on a good package builder in the first place. I have seen packages that
|
|
depend upon themselves, for instance, and some that seem to depend on
|
|
packages that will break other things. Keep this in mind.
|
|
|
|
<p>Sometimes RPM will whine about a dependency which is installed but
|
|
isn't registered. Perhaps you installed it not using an RPM for the
|
|
package (ie OpenSSL). To get around this, you can force it to ignore
|
|
dependencies:
|
|
|
|
<p> rpm -ivv --nodeps (package)
|
|
|
|
<p>Note that this isn't always wise and should only be done when you know
|
|
what you are getting youself into. This will rarely break installed stuff,
|
|
but may mean the installed package wont work properly.
|
|
|
|
<p>On rare occassion RPM will mess up and insist that you have a package
|
|
installed when you don't. While this is usually a sign that something is
|
|
amiss, it can be worked around. Just force the installation:
|
|
|
|
<p> rpm -ivv --force (package)
|
|
|
|
<p>Beware. Just like when you ignored the dependencies, forcing a package
|
|
to install may not be wise. Bear in mind that your machine could burst
|
|
into flames or simply stop working. Caveat emptor and all that.
|
|
|
|
<p>This probably wins the award for one of the coolest features in RPM:
|
|
network installations. Sometimes, you don't have network clients on a
|
|
system but you need to install them via RPM. RPM has built in FTP and web
|
|
client sowftare to handle this:
|
|
|
|
<p> rpm -iv <a
|
|
href="ftp://ftp.redhat.com/path/package.rpm">ftp://ftp.redhat.com/path/package.rpm</a>
|
|
|
|
<br> rpm -iv <a
|
|
href="http://www.me.com/path/package.rpm">http://www.me.com/path/package.rpm</a>
|
|
|
|
<p>I don't think it can do SSL HTTP connections, though. Debian's packages
|
|
can do this, as can BSD packages. I don't think most commercial tools can
|
|
do this, though.
|
|
|
|
<h3> Managing Your Packages</h3>
|
|
|
|
OK, you know how to install packages. But let's say you want to work with
|
|
some packages before you, either installed or not. How can you do this?
|
|
Well, simply put, you can use package management features in rpm to deal
|
|
with packages, ones that are installed already or ones that are not, to
|
|
look inside of them. This can include verifying packages, too.
|
|
|
|
<p>When you get a new package, you may want to examine it to see what it
|
|
offers. Using query mode, you can peek inside. To simply query a package
|
|
and get some generic information about it, just simply:
|
|
|
|
<p> rpm -qp (package)
|
|
|
|
<p>This should bring just the name of the package. Pretty boring, isnt it?
|
|
A much more useful method is to get the package information from the
|
|
package itself:
|
|
|
|
<p> rpm -qip (package)
|
|
|
|
<p>This will bring up the author, build host and date, whether it's installed
|
|
yet, etc, about a package. Also included is a summary about the package's
|
|
functionality and features.
|
|
|
|
<p>All of this is nice, but let's say you want to see what is really
|
|
inside the package, what files are inside of it? Well, you can list the
|
|
contents of a package, much like you would get the table of contents of a
|
|
tar archive (using tar -tvf):
|
|
|
|
<p> rpm -qlp (package)
|
|
|
|
<p>This will list all of the files within the archive, using their full
|
|
pathnames. I use this often to see what will be installed with a package,
|
|
but most importantly where. I like to stick to conventions about putting
|
|
stuff in their expected places, but some packagers do not. Lastly, to show
|
|
all of the packages you have installed on your system, use:
|
|
|
|
<p> rpm -qa
|
|
|
|
<p>This will bring up a list of packages installed on the current system.
|
|
It may be useful to sort them (by piping through sort, rpm -qa | sort).
|
|
Use these names when uninstalling packages (below).
|
|
|
|
<p>One of my favorite things about RPM is how it can verify packages. This
|
|
is useful in detecting a compromised machine, or a binary that may be
|
|
missing or modified due to some error on your part. To verify one package,
|
|
just point rpm at it with the -V flag:
|
|
|
|
<p> rpm -V (package)
|
|
|
|
<p>This should bring up a brief description of wether or not the package
|
|
checks out. To verify all packages installed on a system, it is quite
|
|
simply:
|
|
|
|
<p> rpm -Va
|
|
|
|
<p>Verify mode brings up several statistics about a file. Their shorthand
|
|
is as follows:
|
|
|
|
<br> <table> <tr> <td>5</td>
|
|
|
|
<td>MD5 sum</td> </tr>
|
|
|
|
<tr> <td>S</td>
|
|
|
|
<td>File size</td> </tr>
|
|
|
|
<tr> <td>L</td>
|
|
|
|
<td>Symlink</td> </tr>
|
|
|
|
<tr> <td>T</td>
|
|
|
|
<td>Mtime (modification time)</td> </tr>
|
|
|
|
<tr> <td>D</td>
|
|
|
|
<td>Device</td> </tr>
|
|
|
|
<tr> <td>U</td>
|
|
|
|
<td>User</td> </tr>
|
|
|
|
<tr> <td>G</td>
|
|
|
|
<td>Group</td> </tr>
|
|
|
|
<tr> <td>M</td>
|
|
|
|
<td>Mode (includes permissions and file type)</td> </tr> </table>
|
|
|
|
<p>Sometimes they're meaningless, for example if you modify your
|
|
/etc/inetd.conf file it will show up as a different size and MD5 sum.
|
|
However, some things shouldn't change, like /bin/login. Hence, rpm -Va can
|
|
be a useful quick security check, suggesting which things need more
|
|
peering into.
|
|
|
|
<p>One of the great things about package management we stated at the
|
|
outset was the ease with which upgrading can be performed. RPM has two
|
|
sometimes confusing options to upgrading packages. The first is a simple
|
|
upgrade:
|
|
|
|
<p> rpm -U (package)
|
|
|
|
<p>What is confusing about it is it's resulting action if the package is
|
|
not yet installed. If it finds it, the package is upgraded. If it doesn't
|
|
find it, you are upgraded to it, meaning the package is installed. This
|
|
can be scary sometimes if you don't mean to install a package and an
|
|
update comes out, which you blindly follow. Because of this, I suggest
|
|
using "freshen" on packages you only want to ensure you have the latest
|
|
version of:
|
|
|
|
<p> rpm -F (package)
|
|
|
|
<p>This will only update installed packages, and not install the package
|
|
if it is missing.
|
|
|
|
<p>Upgrades are done in an interesting fashion, too. The new version is first
|
|
installed and the differences with the old version are noted. Then the
|
|
older version is removed, but only the unique portions of it so as not to
|
|
remove the new portions. Imagine if /usr/local/bin/netscape were upgraded
|
|
and then removed, that would defeat the whole effort!
|
|
|
|
<h3> Uninstalling an RPM</h3>
|
|
|
|
You can install, upgrade, and manage, and hence you can definitely
|
|
uninstall using RPM. The flag to use is -e, and many of the same
|
|
conditions for installation apply for removal. To silently uninstall an
|
|
RPM package, use:
|
|
|
|
<p> rpm -e (package)
|
|
|
|
<p>Note that, unlike for installations and upgrades, package here refers
|
|
not to package-version.i386.rpm, but instead to package-version. These are
|
|
the values reported in query mode, so use those. You should be able to get
|
|
all components of a package for removal by specifying the most generic,
|
|
common part of the name, ie for linuxconf and linuxconf-devel, specify
|
|
linuxconf. Dependencies can also be avoided:
|
|
|
|
<p> rpm -e --nodeps (package)
|
|
|
|
<p>The same caveats apply here, as well, you could wind up breaking more
|
|
stuff than you anticipated. Verbosity flags can also be added, just like
|
|
in installations.
|
|
|
|
<h3> Some Notes about RPMs</h3>
|
|
|
|
Sometimes maintainers build rather stupid dependencies for their RPMs.
|
|
Case in point, libsafe. It has a wierd dependency: itself. As such, I
|
|
usually find I have to install --nodeps to get it to install properly.
|
|
Other times a package will contain extra junk, and you could wind up
|
|
installing more than you had planned for.
|
|
|
|
<p>My biggest complaint are RPMs that have a name that doesn't suit the
|
|
function of the pieces. While this can be gotten around by digging around
|
|
using the query tools as described above, it's more time than I care to
|
|
waste. Name your RPMs well, I suggest.
|
|
|
|
<h3> Getting RPM</h3>
|
|
|
|
You can get RPM for any Linux or UNIX variant, as it is Open Source. RPM
|
|
comes native in Red Hat Linux, and some derivatives. Versions 3.0 and above
|
|
are recomended for compatability, some stupid stuff went on before that
|
|
that 3.0 hopes to fix. Version 4.0 reportedly has a different database
|
|
format, and so I reccomend checking around for how to get around this
|
|
issue before you upgrade to 4.0. I'm not sure if can simply rebuild the
|
|
database in 4.0 to remedy this.
|
|
|
|
<p>RPM is normally distributed as an RPM of itself. Cute, eh? Luckily, it
|
|
also comes in a gzipped tarball and also in source form. I have RPM
|
|
installed on Slackware, for example, and could install it on IRIX or
|
|
Solaris if I so desired. It's nearly useless on non-Linux platforms as
|
|
rarely are packages built in RPM for other UNIX variants.
|
|
|
|
<h3> Coming Next Time</h3>
|
|
|
|
In the upcoming second half of this documentation we will taking a look at
|
|
how to build an RPM for yourself. We'll look at the spec files, layout in
|
|
/usr/src and the building flags. It's pretty easy once you learn a few
|
|
basics.
|
|
|
|
<h3> Resources</h3>
|
|
|
|
The best place to start is the online website for RPM, <a
|
|
href="http://www.rpm.org/">http://www.rpm.org/</a>. There you will find
|
|
the book 'Maximum RPM', which covers how to use, build, and even
|
|
programming with the RPM API. The RPM help page (rpm -h) is also quite
|
|
useful once you learn a few basics. To find RPM archives, check <a
|
|
href="http://www.rpmfind.net/">http://www.rpmfind.net/</a>, which
|
|
maintains a great searchable database of packages for various
|
|
distributions and versions on a variety of platforms. Very useful.
|
|
|
|
|
|
|
|
|
|
<!-- *** BEGIN bio *** -->
|
|
<SPACER TYPE="vertical" SIZE="30">
|
|
<P>
|
|
<H4><IMG ALIGN=BOTTOM ALT="" SRC="../gx/note.gif">Jose Nazario</H4>
|
|
José is a Ph.D. student in the department of biochemistry at Case
|
|
Western Reserve University in Cleveland, OH. He has been using UNIX for
|
|
nearly ten years, and Linux since kernels 1.2.
|
|
|
|
<!-- *** END bio *** -->
|
|
|
|
<!-- *** BEGIN copyright *** -->
|
|
<P> <hr> <!-- P -->
|
|
<H5 ALIGN=center>
|
|
|
|
Copyright © 2001, Jose Nazario.<BR>
|
|
Copying license <A HREF="../copying.html">http://www.linuxgazette.com/copying.html</A><BR>
|
|
Published in Issue 68 of <i>Linux Gazette</i>, July 2001</H5>
|
|
<!-- *** END copyright *** -->
|
|
|
|
<!--startcut ==========================================================-->
|
|
<HR><P>
|
|
<CENTER>
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="mitchell.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue68/nazario.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="nazario2.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
</CENTER>
|
|
</BODY></HTML>
|
|
<!--endcut ============================================================-->
|