| Add comments here | |
|
|
| |
Here you will, first and foremost, learn to build packages from source,
following on from your knowledge of Makefiles in Chapter
25. 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, tar'ed 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 untaring 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 install 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 it.
COPYING- The GNU General Public License.
AUTHORS- A list of major contributors.
ChangeLog- A especially 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 will install using only the three following commands:
|
./configure
make
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 now go through 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 where you are going to build
such custom packages. Now
|
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 indicates bug fixes.
|
| |
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 comply27.1.
|
./configure --prefix=/opt/cooledit
|
Here, -prefix indicates the top-level directory under which
the package will be installed. (See Section 20.). Always also
try:
to see package specific options. Another trick sets compile options:
|
CFLAGS='-O2 -fomit-frame-pointer -s -pipe' ./configure --prefix=/opt/cooledit
|
-O2- Sets compiler optimisations to be as-fast-as-possible-without-making-the-binary-larger.
(
-O3 almost 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 analysing 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- Don't 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 anything up to several hours depending
on the amount of code and your CPU power27.2.
You can also do
if you decide that you would rather compile with debug support after all.
|
| |
Install the package with,
A nice trick to install into a different subdirectory is27.3:
|
mkdir /tmp/cooledit
make install prefix=/tmp/cooledit
|
You can use this to pack up the completed build for taring onto
a different system. You should however never try to run a package from a
different directory to the one it was -prefix'd to install into, since
most packages compile-in the location of data they install.
|
| |
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, where vendors have neglected to include certain files.
|
| |
|
| |
Through this section we will place Debian examples inside braces,
( ... ). Since these are examples from actual
systems they will 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.
|
| |
The <source-version> is the version on the original
tar file (as above). The <package-version>
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 Sparc27.4 machine, ppc for a
Power PC27.5, alpha for a
DEC Alpha27.6 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 can be done with, for example (Debian automatically
chooses an upgrade if the package is already present):
|
rpm -U mirrordir-0.10.49-1.i386.rpm
( dpkg -i mirrordir_0.10.49-1.deb )
|
and then completely un-installing with
|
rpm -e mirrordir
( dpkg --purge mirrordir )
|
With Debian, a package removal does not remove
configuration files, allowing you to reinstall later:
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 a track of these dependencies.
Often you will get an error: failed dependencies: (or
dependency problems for Debian) message when trying to install. This
means that other packages must be installed first. The same might happen
when trying 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 where exim is an adequate substitute.
In such cases the option -nodeps skips dependency checking.
|
rpm -i --nodeps <rpm-file>
( dpkg --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),
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, llist) status)
|
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,
|
rpm -qi <package>
( dpkg -s <package> )
|
To list libraries and other packages required by a some package,
|
rpm -qR <package>
( dpkg -s <package> | grep Depends )
|
To list what other packages require this one (with Debian we can check
be attempting a remove 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 package27.7,
|
rpm -ql <package>
( dpkg -L <package> )
|
Package file lists are especially useful for finding
what commands a package provides, as well as what documentation. 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 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:` )
|
|
| |
|
| |
To query package a file that have 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. A list of other tags that can be queried is:
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>
|
Which will create a directory <out-directory>
and place the files in them. You can also dump the package as a tar file
with:
|
dpkg --fsys-tarfile <deb-file>
|
or for an .rpm file,
|
| |
Finally package files lists can be queried with,
|
rpm -qip <rpm-file>
( dpkg -I <deb-file> )
rpm -qlp <rpm-file>
( dpkg -c <deb-file> )
|
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 --
comprised of the commands apt-cache, apt-cdrom,
apt-config and apt-get); and dselect which is an
interactive text based package selector. Between these you can do some
sophisticated time-saving things like recursively resolving package
dependencies through automatic downloads -- i.e. just mention the
package and APT will find it and what it depends on, then download and
install everything for you. See apt8, sources.list5 and
apt.conf5 for more info.
|
| |
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.
|
| |
|
| |
|
