Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

 Purchase  Copyright © 2002 Paul Sheer. Click here for copying permissions.  Home 

next up previous contents
Next: 25. Introduction to IP Up: rute Previous: 23. Shared Libraries   Contents


24. Source and Binary Packages

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.

24.1 Building GNU Source Packages

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:

This is a standard document beginning with the line `` These are generic installation instructions.'' Since all GNU packages are installed in the same way, this file should always be the same.
News of interest to users.
Any essential information. This is usually an explanation of what the package does, promotional material, and anything special that need be done to install the package.
The GNU General Public License.
A list of major contributors.
A specially formatted list containing a history of all changes ever done to the package, by whom, and on what date. Used to track work on the package.
Being GNU standards compliant should also mean that the package can be installed with only the three following commands:

make 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/src
tar -xvzf cooledit-3.17.2.tar.gz
cd 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

Sets compiler optimizations to be ``as fast as possible without making the binary larger.'' ( -O3 almost never provides an advantage.)
Permits the compiler to use one extra register that would normally be used for debugging. Use this option only when you are absolutely sure you have no interest in analyzing any running problems with the package.
Strips the object code. This reduces the size of the object code by eliminating any debugging data.
Instructs not to use temporary files. Rather, use pipes to feed the code through the different stages of compilation. This usually speeds compilation.

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.]


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/cooledit
make 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.

24.2 RedHat and Debian Binary Packages

In this section, we place Debian examples inside parentheses, ( ... ). Since these are examples from actual systems, they do not always correspond.

24.2.1 Package versioning

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>.deb )

For example,

( 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.

24.2.2 Installing, upgrading, and deleting

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.

24.2.3 Dependencies

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.

24.2.4 Package queries

.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> )


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

( 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> )

24.2.5 File lists and file queries

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- 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:` )

24.2.6 Package verification

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 [*]. 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.

24.2.7 Special queries

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:


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.

24.2.8 dpkg/ apt versus rpm

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.

24.3 Source Packages -- Building RedHat and Debian Packages

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.

next up previous contents
Next: 25. Introduction to IP Up: rute Previous: 23. Shared Libraries   Contents