As with any other large, complex subject, there are always some leftovers -- things that just don't seem to fit in any one category. RPM is no exception. This chapter covers those aspects of RPM that can only be called ``miscellania''...
The following options are not normally used on a day to day basis. However, some of them can be quite important when the need arises. One such option is - -rebuilddb.
We all hope the day never comes, and for many of us, it never does. But still, there is a chance that one day, while you're busy using RPM to install or upgrade a package, you'll see this message:
free list corrupt (42)- contact rpm-list@@redhat.com
Once this happens, you'll find there's very little that you can do, RPM-wise. However, before you fire off an e-mail to the RPM mailing list, you might try the - -rebuilddb option. The format of the command is simple:
rpm - -rebuilddb
The command produces no output, either. After a few minutes, it completes with nary a peep. Here's an example of - -rebuilddb being used on an RPM database that wasn't corrupt. First, let's look at the files that comprise the database:
# cd /var/lib/rpm
# ls
total 3534 -rw-r--r-- 1 root root 1351680 Oct 17 10:35 fileindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 10:35 groupindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 10:35 nameindex.rpm -rw-r--r-- 1 root root 2342536 Oct 17 10:35 packages.rpm -rw-r--r-- 1 root root 16384 Oct 17 10:35 providesindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 10:35 requiredby.rpm #
Then, we issue the command:
# rpm - -rebuilddb
#
After a few minutes, the command completes, and we take a look at the files again:
# ls
total 3531 -rw-r--r-- 1 root root 1351680 Oct 17 20:50 fileindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 20:50 groupindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 20:50 nameindex.rpm -rw-r--r-- 1 root root 2339080 Oct 17 20:50 packages.rpm -rw-r--r-- 1 root root 16384 Oct 17 20:50 providesindex.rpm -rw-r--r-- 1 root root 16384 Oct 17 20:50 requiredby.rpm #
You'll note that packages.rpm decreased in size. This is due to a
side-effect of the
- -rebuilddb option - While it is going through the database,
it is getting rid of unused portions of the database. Our example was
performed on a newly installed system where only one or two packages had
been upgraded, so the reduction in size was small. For a system that has
been through a complete upgrade, the difference would be more dramatic.
Does this mean that you should rebuild the database every once in a while? Not really. Since RPM eventually will make use of the holes, there's no major advantage to regular rebuilds. However, when an RPM-based system has undergone a major upgrade, it certainly wouldn't hurt to spend a few minutes using - -rebuilddb to clean things up.
If you are already using RPM, the - -initdb option is one you'll probably never have to use. The - -initdb option is used to create a new RPM database. That's why you'll probably not need it if you're already using RPM -- you already have an RPM database.
It might seem that the - -initdb option would be dangerous. After all, won't it trash your current database if you mistakenly use it? Fortunately, the answer is no. If there is an RPM database in place already, it's still perfectly safe to use the option, even though it won't accomplish much. As an example, here's a listing of the files that make up the RPM database on a Red Hat Linux system:
# ls /var/lib/rpm
total 3559 -rw-r--r-- 1 root root 16384 Jan 8 22:10 conflictsindex.rpm -rw-r--r-- 1 root root 1351680 Jan 8 22:10 fileindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 groupindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 nameindex.rpm -rw-r--r-- 1 root root 2349640 Jan 8 22:10 packages.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 providesindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 requiredby.rpm #
Next, let's use the - -initdb option, just to see what it does to this database:
# rpm - -initdb
# ls /var/lib/rpm
total 3559 -rw-r--r-- 1 root root 16384 Jan 8 22:10 conflictsindex.rpm -rw-r--r-- 1 root root 1351680 Jan 8 22:10 fileindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 groupindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 nameindex.rpm -rw-r--r-- 1 root root 2349640 Jan 8 22:10 packages.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 providesindex.rpm -rw-r--r-- 1 root root 16384 Jan 8 22:10 requiredby.rpm #
Since an RPM database existed already, the - -initdb option did no harm to it -- there was no change to the database files.
The only other option that can be used with - -initdb is - -dbpath. This permits the easy creation of a new RPM database in the directory specified with the - -dbpath option.
Adding the - -quiet option to any RPM command directs RPM to produce as little output as possible. For example, RPM's build command (the subject of the second half of this book) normally produces reams of output; by adding the - -quiet option, this is all you'll see:
# rpm -ba - -quiet bother-3.5.spec
* Package: bother
1 block
3 blocks
#
The - -quiet option can silence even the mighty -vv option:
# rpm -Uvv -quiet eject-1.2-2.i386.rpm
#
RPM includes a concise built-in help message for those times when you need a reminder about a particular command. Normally you'll want to use the - -help option by itself, though you might want to pipe the output through a pager such as less, since the output is more than one screen long:
# rpm - -help|less
RPM version 2.3
Copyright (C) 1995 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License
usage:
--help - print this message
--version - print the version of rpm being used
all modes support the following arguments:
--rcfile <file> - use <file> instead of /etc/rpmrc and $HOME/.rpmrc
-v - be a little more verbose
-vv - be incredibly verbose (for debugging)
-q - query mode
--root <dir> - use <dir> as the top level directory
--dbpath <dir> - use <dir> as the directory for the database
--queryformat <s> - use s as the header format (implies -i)
install, upgrade and query (with -p) allow ftp URL's to be used in place
of file names as well as the following options:
--ftpproxy <host> - hostname or IP of ftp proxy
--ftpport <port> - port number of ftp server (or proxy)
This is just the first screen of RPM's help command. To see the rest, give the command a try. Practically everything there is to know about RPM is present in the - -help output. It's a bit too concise to learn RPM from, but it's enough to refresh your memory when the syntax of a particular option escapes you.
If you're not sure what version of RPM is presently installed on your system, the easiest way to find out is to ask RPM itself using the - -version option:
# rpm - -version
RPM version 2.3
#
From time to time, you might find it necessary to extract one or more files from a package file. One way to do this would be to:
An easier way would be to use rpm2cpio.
As the name implies, rpm2cpio takes an RPM package file and converts it to a cpio archive. Because it's written to be used primarily as a filter, there's not much to be specified. rpm2cpio takes only only one argument, and even that's optional!
The optional argument is the name of the package file to be converted. If there is no filename specified on the command line, rpm2cpio will simply read from standard input and convert that to a cpio archive. Let's give it a try:
# rpm2cpio logrotate-1.0-1.i386.rpm
0707020001a86a000081a4000000000000000000000001313118bb000002c200000008000
000030000000000000000000000190000e73eusr/man/man8/logrotate.8." logrotate
- log fi
le rotator
.TH rpm 8 "28 November 1995" "Red Hat Software" "Red Hat Linux"
.SH NAME
(We've just shown the first few lines of output.)
What on earth is all that stuff? Remember, rpm2cpio is written as a filter. It writes the cpio archive contained in the package file to standard output, which, if you've not redirected it somehow, is your screen. Here's a more reasonable example:
# rpm2cpio logrotate-1.0-1.i386.rpm > blah.cpio
# file blah.cpio
blah.cpio: ASCII cpio archive (SVR4 with CRC)
#
Here we've directed rpm2cpio to convert the logrotate package file. We've also redirected rpm2cpio's output to a file called blah.cpio. Next, using the file command, we find that the resulting file is indeed a true-blue cpio archive file. The following command is entirely equivalent to the one above and shows rpm2cpio's ability to read the package file from its standard input:
# cat logrotate-1.0-1.i386.rpm | rpm2cpio > blah.cpio
#
While there's nothing wrong with using rpm2cpio to actually create a cpio archive file, it's takes a few more steps and uses a bit more disk space than is strictly necessary. A somewhat cleaner approach would be to pipe rpm2cpio's output directly into cpio:
# rpm2cpio logrotate-1.0-1.i386.rpm | cpio -t
usr/man/man8/logrotate.8
usr/sbin/logrotate
14 blocks
#
In this example, we used the -t option to direct cpio to produce a ``table of contents'' of the archive created by rpm2cpio. This can make it much easier to get the right filename and path when you want to extract a file.
Continuing the example above, let's extract the man page from the logrotate package. In the table of contents, we see that the full path is usr/man/man8/logrotate.8. All we need to do is to use the filename and path as shown below:
# rpm2cpio logrotate-1.0-1.i386.rpm |cpio -ivd usr/man/man8/logrotate.8
usr/man/man8/logrotate.8
14 blocks
#
In this case, the cpio options -i, -v, and -d direct cpio to:
So where did the file end up? The last option (-d) to cpio provides a hint. Let's take a look:
# ls -al
total 5
-rw-rw-r- 1 root root 3918 May 30 11:02 logrotate-1.0-1.i386.rpm
drwx--- 3 root root 1024 Jul 14 12:42 usr
# cd usr
# ls -al
total 1
drwx--- 3 root root 1024 Jul 14 12:42 man
# cd man
# ls -al
total 1
drwx--- 2 root root 1024 Jul 14 12:42 man8
# cd man8
# ls -al
total 1
-rw-r-r- 1 root root 706 Jul 14 12:42 logrotate.8
# cat logrotate.8
.\" logrotate - log file rotator .TH rpm 8 "28 November 1995" "Red Hat Software" "Red Hat Linux" .SH NAME logrotate \- log file rotator .SH SYNOPSIS \fBlogrotate\fP [configfiles] .SH DESCRIPTION \fBlogrotate\fP is a tool to prevent log files from growing without
Since the current directory didn't have a usr/man/man8/ path in it, the -d option caused cpio to create all the directories leading up to the logrotate.8 file in the current directory. Based on this, it's probably safest to use cpio outside the normal system directories unless you're comfortable with cpio, and you know what you're doing!
One day, you may run across a package file with a name similar to the following:
etcskel-1.0-3.src.rpm
Notice the src. Is that a new kind of computer? If you use RPM on an Intel-based computer, you'd normally expect to find i386 there. Maybe someone messed up the name of the file. Well, we know that the file command can display information about a package file, even if the filename has been changed. We've used it before to figure out what package a file contains:
# file foo.bar
foo.bar: RPM v2 bin i386 eject-1.2-2
#
In this example, foo.bar is an RPM version 2 file, containing an executable package - hence, the ``bin'' - built for Intel processors - the ``i386''. The package is eject version 1.2, release 2.
Let's try the file command on this mystery file and see what we can find out about it:
# file etcskel-1.0-3.src.rpm
etcskel-1.0-3.src.rpm: RPM v2 src i386 etcskel-1.0-3
#
Well, it's a package file all right - for version 1.0, release 3 of the etcskel package. It's in RPM version 2 format, and built for Intel-based systems. But what does the ``src'' mean?
This package file contains not the executable, or ``binary'', files that a normal package contains, but rather the ``source'' files required to create those binaries. When programmers create a new program, they write the instructions, often called ``code'', in one or more files. The source code is then compiled into a binary that can be executed by the computer.
As part of the process of building package files (a process we cover in great detail in the second half of this book), two types of package files are created:
The source package contains everything needed to recreate not only the programs and associated files that are contained in the binary package file, but the binary and source package files themselves.
The following discussion is going to get rather technical. Unless you're the type of person who likes to take other people's code and modify it, chances are you won't need much more information than this. But if you're still interested, let's explore further.
In the case of source package files, one of the things that can be done with them is that they can be installed. Let's try an install of a source package:
# rpm -i cdp-0.33-3.src.rpm
#
Well that doesn't tell us very much and, take our word for it, adding -v doesn't improve the situation appreciably. Let's haul out the big guns and try -vv:
# rpm -ivv cdp-0.33-3.src.rpm
D: installing cdp-0.33-3.src.rpm
Installing cdp-0.33-3.src.rpm
D: package is a source package major = 2
D: installing a source package
D: sources in: ///usr/src/redhat/SOURCES
D: spec file in: ///usr/src/redhat/SPECS
D: file "cdp-0.33-cdplay.patch" complete
D: file "cdp-0.33-fsstnd.patch" complete
D: file "cdp-0.33.spec" complete
D: file "cdp-0.33.tgz" complete
D: renaming ///usr/src/redhat/SOURCES/cdp-0.33.spec
to
///usr/src/redhat/SPECS/cdp-0.33.spec
#
What does this output tell us? Well, RPM recognizes that the file is a source package. It mentions that sources (we know what they are) are in /usr/src/redhat/SOURCES. Let's take a look:
# ls -al /usr/src/redhat/SOURCES/
-rw-rw-r- 1 root root 364 Apr 24 22:35 cdp-0.33-cdplay.patch
-rw-r-r- 1 root root 916 Jan 8 12:07 cdp-0.33-fsstnd.patch
-rw-r-r- 1 root root 148916 Nov 10 1995 cdp-0.33.tgz
#
There are some files that seem to be related to cdp there. The two files ending with ``.patch'' are patches to the source. RPM permits patches to be processed when building binary packages. The patches are bundled along with the original, unmodified sources in the source package.
The last file is a gzipped tar file. If you've gotten software off the Internet, you're probably familiar with tar files, gzipped or not. If we look inside the file, we should see all the usual kinds of things: README files, a Makefile or two, and some source code:
# tar ztf cdp-0.33.tgz
cdp-0.33/COPYING
cdp-0.33/ChangeLog
cdp-0.33/INSTALL
cdp-0.33/Makefile
cdp-0.33/README
cdp-0.33/cdp
cdp-0.33/cdp-0.33.lsm
cdp-0.33/cdp.1
cdp-0.33/cdp.1.Z
cdp-0.33/cdp.c
cdp-0.33/cdp.h
There's more, but you get the idea. OK, so there are the sources. But what is that ``spec'' file mentioned in the output? It mentions something about ``/usr/src/redhat/SPECS'', so let's see what we have in that directory:
# ls -al /usr/src/redhat/SPECS
-rw-r-r- 1 root root 397 Apr 24 22:36 cdp-0.33.spec
Without making a long story too short, a spec file contains information used by RPM to create the binary and source packages. Using the spec file, RPM:
The neatest part of this is that RPM does this all automatically, under the control of the spec file. That's about all we're going to say about how RPM builds packages. For more information, please refer to the second half of this book.
As we've noted several times, we'll be covering the entire subject of building packages with RPM, in the second half of the book. Be forewarned, however: Package building, while straightforward, is not a task for people new to programming. But if you've written a program or two, you'll probably find RPM's package building a piece of cake.