| Purchase | Copyright © 2002 Paul Sheer. Click here for copying permissions. | Home |
|
|
| |
In this chapter you will, first and foremost, learn to build packages from source, building on your knowledge of Makefiles in Chapter 22. Most packages, however, also come as .rpm (RedHat) or .deb (Debian) files, which are discussed further below.
Almost all packages originally come as C sources, tared and available from one of the many public FTP sites, like metalab.unc.edu. Thoughtful developers would have made their packages GNU standards compliant. This means that un tarring the package will reveal the following files inside the top-level directory:
|
./configuremakemake install |
It also usually means that packages will compile on any UNIX system. Hence, this section should be a good guide to getting LINUX software to work on non-LINUX machines.
An example will illustrate these steps. Begin by downloading cooledit from metalab.unc.edu in the directory /pub/Linux/apps/editors/X/cooledit, using ftp. Make a directory /opt/src in which to build such custom packages. Now run
|
cd /opt/srctar -xvzf cooledit-3.17.2.tar.gzcd cooledit-3.17.2 |
You will notice that most sources have the name package -major .minor .patch .tar.gz. The major version of the package is changed when the developers make a substantial feature update or when they introduce incompatibilities to previous versions. The minor version is usually updated when small features are added. The patch number (also known as the patch level) is updated whenever a new release is made and usually signifies bug fixes.
At this point you can apply any patches you may have. See Section 20.7.3.
You can now ./configure the package. The ./configure script is generated by autoconf--a package used by developers to create C source that will compile on any type of UNIX system. The autoconf package also contains the GNU Coding Standards to which all software should comply. [ autoconf is the remarkable work of David MacKenzie. I often hear the myth that UNIX systems have so diverged that they are no longer compatible. The fact that sophisticated software like cooledit (and countless others) compiles on almost any UNIX machine should dispel this nonsense. There is also hype surrounding developers ``porting'' commercial software from other UNIX systems to LINUX. If they had written their software in the least bit properly to begin with, there would be no porting to be done. In short, all LINUX software runs on all UNIXs. The only exceptions are a few packages that use some custom features of the LINUX kernel.]
|
./configure --prefix=/opt/cooledit |
Here, --prefix indicates the top-level directory under which the package will be installed. (See Section 17.2.). Always also try
|
./configure --help |
to see package-specific options.
Another trick sets compile options:
|
CFLAGS='-O2 -fomit-frame-pointer -s -pipe' ./configure --prefix=/opt/cooledit |
Compile the package. This can take up to several hours depending on the amount of code and your CPU power. [ cooledit will compile in under 10 minutes on any entry-level machine at the time of writing.]
|
make |
You can also run
|
make CFLAGS='-O0 -g' |
if you decide that you would rather compile with debug support after all.
Install the package with
|
make install |
A nice trick to install into a different subdirectory is [Not always supported.]:
|
mkdir /tmp/cooleditmake install prefix=/tmp/cooledit |
You can use these commands to pack up the completed build for un taring onto a different system. You should, however, never try to run a package from a directory different from the one it was --prefixed to install into, since most packages compile in this location and then access installed data from beneath it.
Using a source package is often the best way to install when you want the package to work the way the developers intended. You will also tend to find more documentation, when vendors have neglected to include certain files.
In this section, we place Debian examples inside parentheses, ( ... ). Since these are examples from actual systems, they do not always correspond.
The package numbering for RedHat and Debian packages is often as follows (although this is far from a rule):
|
<package-name>-<source-version>-<package-version>.<hardware-platform>.rpm( <package-name>_<source-version>-<package-version>.deb ) |
For example,
|
bash-1.14.7-22.i386.rpm( bash_2.03-6.deb ) |
is the Bourne Again Shell you are using, major version 1, minor version 14, patch 7, package version 22, compiled for an Intel 386 processor. Sometimes, the Debian package will have the architecture appended to the version number, in the above case, perhaps bash_2.03-6_i386.deb.
The <source-version> is the version on the original .tar file (as above). The <package-version>, also called the release, refers to the .rpm file itself; in this case, bash-1.14.7-22.i386.rpm has been packed together for the 8th time, possibly with minor improvements to the way it installs with each new number. The i386 is called the architecture and could also be sparc for a SPARC [Type of processor used in Sun Microsystems workstations] machine, ppc for a PowerPC [Another non-Intel workstation], alpha for a DEC Alpha [High-end 64 bit server/workstation] machine, or several others.
To install a package, run the following command on the .rpm or .deb file:
|
rpm -i mirrordir-0.10.48-1.i386.rpm( dpkg -i mirrordir_0.10.48-2.deb ) |
Upgrading (Debian automatically chooses an upgrade if the package is already present) can be done with the following command,
|
rpm -U mirrordir-0.10.49-1.i386.rpm( dpkg -i mirrordir_0.10.49-1.deb ) |
and then completely uninstalling with
|
rpm -e mirrordir( dpkg --purge mirrordir ) |
With Debian, a package removal does not remove configuration files, thus allowing you to revert to its current setup if you later decide to reinstall:
|
dpkg -r mirrordir |
If you need to reinstall a package (perhaps because of a file being corrupted), use
|
rpm -i --force python-1.6-2.i386.rpm |
Debian reinstalls automatically if the package is present.
Packages often require other packages to already be installed in order to work. The package database keeps track of these dependencies. Often you will get an error: failed dependencies: (or dependency problems for Debian) message when you try to install. This means that other packages must be installed first. The same might happen when you try to remove packages. If two packages mutually require each other, you must place them both on the command-line at once when installing. Sometimes a package requires something that is not essential or is already provided by an equivalent package. For example, a program may require sendmail to be installed even though exim is an adequate substitute. In such cases, the option --nodeps skips dependency checking.
|
rpm -i --nodeps <rpm-file>( dpkg -i --ignore-depends=<required-package> <deb-file> ) |
Note that Debian is far more fastidious about its dependencies; override them only when you are sure what is going on underneath.
.rpm and .deb packages are more than a way of archiving files; otherwise, we could just use .tar files. Each package has its file list stored in a database that can be queried. The following are some of the more useful queries that can be done. Note that these are queries on already installed packages only:
To get a list of all packages ( query all, llist),
|
rpm -qa( dpkg -l '*' ) |
To search for a package name,
|
rpm -qa | grep <regular-expression>( dpkg -l <glob-expression> ) |
Try,
|
rpm -qa | grep util( dpkg -l '*util*' ) |
To query for the existence of a package, say, textutils ( query, list),
|
rpm -q textutils( dpkg -l textutils ) |
gives the name and version
|
textutils-2.0e-7( ii textutils 2.0-2 The GNU text file processing utilities. ) |
To get info on a package ( query info, status),
|
rpm -qi <package>( dpkg -s <package> ) |
To list libraries and other packages required by a package,
|
rpm -qR <package>( dpkg -s <package> | grep Depends ) |
To list what other packages require this one (with Debian we can check by attempting a removal with the --no-act option to merely test),
|
rpm -q --whatrequires <package>( dpkg --purge --no-act <package> ) |
To get a file list contained by a package [Once again, not for files but packages already installed.],
|
rpm -ql <package>( dpkg -L <package> ) |
Package file lists are especially useful for finding what commands and documentation a package provides. Users are often frustrated by a package that they ``don't know what to do with.'' Listing files owned by the package is where to start.
To find out what package a file belongs to,
|
rpm -qf <filename>( dpkg -S <filename> ) |
For example, rpm -qf /etc/rc.d/init.d/httpd (or rpm -qf /etc/init.d/httpd) gives apache-mod_ssl-1.3.12.2.6.6-1 on my system, and rpm -ql fileutils-4.0w-3 | grep bin gives a list of all other commands from fileutils. A trick to find all the sibling files of a command in your PATH is:
|
rpm -ql `rpm -qf \`which --skip-alias <command> \``( dpkg -L `dpkg -S \`which <command> \` | cut -f1 -d:` ) |
You sometimes might want to query whether a package's files have been modified since installation (possibly by a hacker or an incompetent system administrator). To verify all packages is time consuming but provides some very instructive output:
|
rpm -V `rpm -qa`( debsums -a ) |
However, there is not yet a way of saying that the package installed is the real package (see Section 44.3.2). To check this, you need to get your actual .deb or .rpm file and verify it with:
|
rpm -Vp openssh-2.1.1p4-1.i386.rpm( debsums openssh_2.1.1p4-1_i386.deb ) |
Finally, even if you have the package file, how can you be absolutely sure that it is the package that the original packager created, and not some Trojan substitution? Use the md5sum command to check:
|
md5sum openssh-2.1.1p4-1.i386.rpm( md5sum openssh_2.1.1p4-1_i386.deb ) |
md5sum uses the MD5 mathematical algorithm to calculate
a numeric hash value based on the file contents, in this
case,
8
e
8
d
8
e
9
5
d
b
7
f
d
e
9
9
c
0
9
e
1
3
9
8
e
4
d
d
3
4
6
8.
This is identical to password hashing described on page
![[*]](crossref.png)
. There is no feasible computational
method of forging a package to give the same MD5 hash; hence,
packagers will often publish their
md5sum results on their web
page, and you can check these against your own as a security
measure.
To query a package file that has not been installed, use, for example:
|
rpm -qp --qf '[%{VERSION}\n]' <rpm-file>( dpkg -f <deb-file> Version ) |
Here, VERSION is a query tag applicable to .rpm files. Here is a list of other tags that can be queried:
| BUILDHOST | OBSOLETES | RPMTAG_PREUN |
| BUILDTIME | OS | RPMVERSION |
| CHANGELOG | PACKAGER | SERIAL |
| CHANGELOGTEXT | PROVIDES | SIZE |
| CHANGELOGTIME | RELEASE | SOURCERPM |
| COPYRIGHT | REQUIREFLAGS | SUMMARY |
| DESCRIPTION | REQUIRENAME | VENDOR |
| DISTRIBUTION | REQUIREVERSION | VERIFYSCRIPT |
| GROUP | RPMTAG_POSTIN | VERSION |
| LICENSE | RPMTAG_POSTUN | |
| NAME | RPMTAG_PREIN |
For Debian, Version is a control field. Others are
| Conffiles | Maintainer | Replaces |
| Conflicts | Package | Section |
| Depends | Pre-Depends | Source |
| Description | Priority | Status |
| Essential | Provides | Suggests |
| Installed-Size | Recommends | Version |
It is further possible to extract all scripts, config, and control files from a .deb file with:
|
dpkg -e <deb-file> <out-directory> |
This command creates a directory <out-directory> and places the files in it. You can also dump the package as a tar file with:
|
dpkg --fsys-tarfile <deb-file> |
or for an .rpm file,
|
rpm2cpio <rpm-file> |
Finally, package file lists can be queried with
|
rpm -qip <rpm-file>( dpkg -I <deb-file> )rpm -qlp <rpm-file>( dpkg -c <deb-file> ) |
which is analogous to similar queries on already installed packages.
Only a taste of Debian package management was provided above. Debian has two higher-level tools: APT (Advanced Package Tool--which comprises the commands apt-cache, apt-cdrom, apt-config, and apt-get); and dselect, which is an interactive text-based package selector. When you first install Debian, I suppose the first thing you are supposed to do is run dselect (there are other graphical front-ends--search on Fresh Meat <http://freshmeat.net/>), and then install and configure all the things you skipped over during installation. Between these you can do some sophisticated time-saving things like recursively resolving package dependencies through automatic downloads--that is, just mention the package and APT will find it and what it depends on, then download and install everything for you. See apt(8), sources.list(5), and apt.conf(5) for more information.
There are also numerous interactive graphical applications for managing RPM packages. Most are purely cosmetic.
Experience will clearly demonstrate the superiority of Debian packages over most others. You will also notice that where RedHat-like distributions have chosen a selection of packages that they thought you would find useful, Debian has hundreds of volunteer maintainers selecting what they find useful. Almost every free UNIX package on the Internet has been included in Debian.
Both RedHat and Debian binary packages begin life as source files from which their binary versions are compiled. Source RedHat packages will end in .src.rpm, and Debian packages will always appear under the source tree in the distribution. The RPM-HOWTO details the building of RedHat source packages, and Debian's dpkg-dev and packaging-manual packages contain a complete reference to the Debian package standard and packaging methods (try dpkg -L dpkg-dev and dpkg -L packaging-manual).
The actual building of RedHat and Debian source packages is not covered in this edition.