Библиотека сайта rus-linux.net
| Purchase | Copyright © 2002 Paul Sheer. Click here for copying permissions. | Home |
|
| |
Next: 25. Introduction to IP Up: rute Previous: 23. Shared Libraries Contents
Subsections
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:
INSTALL- 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- News of interest to users.
README- 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.
COPYING- The GNU General Public License.
AUTHORS- A list of major contributors.
ChangeLog- 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.
|
./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 |
-O2- Sets compiler optimizations to be
``as fast as possible without making the binary larger.''
(
-O3almost never provides an advantage.) -fomit-frame-pointer- 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.
-s- Strips the object code. This reduces the size of the object code by eliminating any debugging data.
-pipe- 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.]
|
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.
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>.<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.
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> ) |
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> ) |
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-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:` ) |
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
![[*]](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.
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:
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.
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: 25. Introduction to IP Up: rute Previous: 23. Shared Libraries Contents