rpm-guide rpm-guide-other-linuxes-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv744
Added Files:
rpm-guide-other-linuxes-en.xml
Log Message:
--- NEW FILE rpm-guide-other-linuxes-en.xml ---
<!-- $Id: -->
<chapter id="ch-other-linuxes">
<title>Using RPM on Non-Red Hat Linuxe</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Dealing with RPM issues on other versions of Linux
</para>
<para>
*RPM standardization
</para>
<para>
*Working around RPM differences when installing RPMs
</para>
<para>
*Working around RPM differences when building RPMs
</para>
<para>
*Dealing with non-RPM-based Linux distributions
</para>
<para>
Although its name was originally the Red Hat Package Manager, RPM
has been adopted by most major Linux distributions. With this
adoption, RPM has moved from its Red Hat roots, and RPM now stands
for the RPM Package Manager.
</para>
<para>
In addition, the RPM package format is being adopted by the Linux
Standards Base (LSB). The LSB defines a set of standards to help
maintain compatibility for all Linux distributions.
</para>
<para>
Cross Reference
</para>
<para>
See www.linuxbase.org for more on the LSB.
</para>
<para>
This chapter covers differences in how Linux distributions use RPM,
ways to work around these differences, and also tools you can use
for non-RPM distributions.
</para>
<sect1>
<title>Troubleshooting RPM Installation Issues</title>
<para>
The main RPM issues when dealing with installing RPMs on other
versions of Linux are:
</para>
<para>
*Different versions of RPM itself
</para>
<para>
*Different divisions of software into packages
</para>
<para>
*Dealing with dependency issues
</para>
<para>
*Different install locations
</para>
<para>
The following sections expand on these issues.
</para>
<sect2>
<title>Dealing with RPM versions</title>
<para>
Red Hat Linux 8.0 ships with RPM version 4.1. Other
distributions of Linux ship with other versions of RPM. Thus,
one of the first commands you can run on another Linux
distribution is the rpm --version command, to see what RPM
version is in use and help identify any issues. For example:
</para>
<para>
$ rpm --version
</para>
<para>
RPM version 4.1
</para>
<para>
Once you know the RPM version, you can plan for any issues that
arise from installing RPMs made with a different RPM version.
For example, RPM 4.0 and higher inserts dependency information
automatically into RPMs. If your Linux distribution runs RPM
3.x, you may need to disable some of the dependency checks, for
example, if you want to install RPMs built under RPM 4.x onto an
RPM 3.x system.
</para>
<para>
On installing RPMs, you can disable the dependency checks with
the --nodeps option. If you do this, though, you should manually
check that the dependencies are really met by your Linux
installation.
</para>
<para>
On the other hand, if you want to install RPMs built on an RPM
3.x system onto an RPM 4.x system, you may need to deal with
package signatures. RPM 4.x versions also automatically check
for signatures. When installing packages on an RPM 4.x system,
you can disable this feature with the --nosignature option.
</para>
<para>
Using these techniques, you should be able to install packages
built with RPM 4.1 on systems that use RPM 3.x versions or vice
versa.
</para>
</sect2>
<sect2>
<title>Dealing with divisions of software into packages</title>
<para>
There is no standardization as to how large applications are
divided into packages on different Linux distributions. This
means that dependencies between packages may differ.
</para>
<para>
If your dependencies are for packages provided with the Linux
distribution, which includes a huge number of packages, you must
address this issue. The package an RPM depends on may not exist
and may not even be needed, on a particular Linux distribution.
</para>
<para>
If instead the dependencies are for files, especially shared
libraries, you should be okay for the most part, unless the
files are located in different directories.
</para>
<para>
The only real solution to this problem is to turn off dependency
checks on installing, with the --nodeps option. Then you must
check manually that your system really does provide all the
necessary dependencies. Use the techniques shown in Chapter 6 to
verify all the dependencies are met on your system.
</para>
<para>
Warning
</para>
<para>
Using the --nodeps option can lead to problems with your RPM
database, because you are installing packages by defeating the
RPM system's safeguards for dependencies. Only use the --nodeps
option if you are really sure the dependencies are met on your
system, even if from a different package than expected.
</para>
</sect2>
<sect2>
<title>Dealing with dependency issues</title>
<para>
One of the toughest areas to deal with is the problem of
dependencies. This topic ranges from the very simple issue of
installing a necessary package to complex issues of shared
library versions or particular Perl modules.
</para>
<para>
Start with the simple case and make certain that you haven���t
failed to install a necessary RPM that provides the right
dependency. In most cases, you can download a vendor-specific
package from your Linux vendor, such as www.suse.com for SuSE
Linux. Most Linux vendors provide HTTP or FTP sites with a large
set of packages created for their distributions. If such a
distribution-specific package solves a dependency issue, this is
the easiest way around the problem.
</para>
<para>
After you verify that you haven't simply omitted a necessary
package, move on to other potential explanations. Another issue
involves shared libraries and ELF, or Extended Linking Format,
symbols. A package may require an older or newer version of a
shared library. Applications that are tied to a particular
version of a shared library can cause problems, since you may
not want to install incompatible versions of a shared library.
</para>
<para>
If the dependency is for a system-shared library, such as the
shared C library, you can often recompile the package (rebuild
from a source RPM) to get the package to use the newer or older
version of the system library. This is possible because most
Linux applications don���t call on version-specific features of
system shared libraries (some do, but most don���t). If the
dependency is for an application-shared library, this is more
serious, since there were likely API changes that could impact
the application. Install the package owning the
application-shared library and again, try to rebuild the package
from the source RPM.
</para>
<para>
Cross Reference
</para>
<para>
You can use the rpm -qf command to query which package owns a
given file. You can use the rpm -q --whatprovides command to
query for which package provides a given capability. Chapter 6
covers more on dependencies.
</para>
<para>
Some packages are considered developer packages. These usually
depend on some base package. For example, the rpm-devel package
depends on the rpm package. The rpm-python package depends on
both the rpm package and the python package (at particular
version numbers as well).
</para>
<para>
This naming scheme of a base package and base-devel is used for
Red Hat Linux packages, but may not be used for other vendor
packages. In any case, you can solve this type of dependency by
finding the relevant base packages that the package you are
trying to install depends on. Consult the manuals that come with
your Linux distribution or browse the online RPM repositories to
see what naming conventions are used for your Linux
distribution.
</para>
<para>
Many packages depend on scripting language interpreters, such as
Perl. Sometimes the dependency is based on scripts used in a
package, such as install or trigger scripts. You can have
problems arise with the locations of these scripting
interpreters. Perl, for example, is usually installed in
/usr/bin/perl on most Linux systems. Another common location is
/usr/local/bin/perl. In addition, packages may depend on
particular add-on modules, especially Perl modules. With most
versions of Linux released in the last few years, you should be
able to override a Perl dependency with the --nodeps option as
long as you have Perl installed.
</para>
<para>
File paths may also cause problems. For example, a file that a
package depends on may be in a different location or owned by a
different package. For this case, you can try to find the
package that owns the file and make sure that package is
installed. If your Linux vendor provides a pre-built RPM
database of all packages, such as the rpmdb-redhat package, you
can query this database to find out which package owns the file
for that version of Linux.
</para>
<para/>
</sect2>
<sect2>
<title>Dealing with install locations</title>
<para>
Linux vendors can install software anywhere. For example, some
distributions place a lot of software under /opt instead of the
more common /usr. From an RPM perspective, this is mostly an
issue with file dependencies and the install location for
packages. Evolving file system standards also help limit this
issue.
</para>
<para>
You can attempt to relocate any package using the --badreloc
option.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 4 covers the --badreloc option.
</para>
<para>
But, while the --badreloc option will relocate the files in a
package, it will not modify the contents of those files. So, any
file inside a package that references files and directory
locations may not work properly, since it may have the old,
invalid, paths.
</para>
<para>
The only real way around this problem is to edit any script
files that come with the package and contain hard-coded paths.
If the paths reside inside binary executables, you need to get a
source RPM for the package, patch the sources and then create a
new RPM.
</para>
</sect2>
<sect2>
<title>When all else fails, rebuild from the source package</title>
<para>
When all of these techniques fail to install a package, you
still have a fallback option. If you have the source RPM for a
package, you can install the source RPM on the new system and
then edit the spec file until you can rebuild a package that
will install on your version of Linux.
</para>
<para>
For example, a set of Build Root Policy (brp) helper scripts are
run at the end of the %install section in an RPM. These scripts
perform tasks such as compressing man pages. The Mandrake brp
scripts use bzip2 compression. Red Hat brp scripts use gzip
compression. This is one case where rebuilding an RPM and then
installing may work best.
</para>
</sect2>
</sect1>
<sect1>
<title>Handling Problems Building RPMs</title>
<para>
Given all these differences, how can you create RPMs while
avoiding problems? With some work setting things up, you can
create an RPM build environment that solves most vendor issues.
This depends on taking a methodical approach to building your
packages and using techniques to avoid vendor issues wherever
possible.
</para>
<para>
When building RPMs, you will face many of the same problems@@mdand
solutions@@mdas when installing RPMs. For example, due to the
different ways Linux vendors divide software into packages, your
RPMs will likely have issues defining the proper dependencies.
There are also a number of issues that apply only when building
RPMs.
</para>
<para>
The following sections cover the main issues when building RPMs.
</para>
<sect2>
<title>Writing distribution-specific packages</title>
<para>
One of the ways around all the differences between Linux
distributions in RPM usage is to define distribution-specific
packages. To do this, you create a separate package on each
Linux distribution you support.
</para>
<para>
That���s a lot of work. If possible, fit the differences into
macros and use a single spec file to reduce some of this work.
This technique works up to a point. Sometimes, your spec file
becomes too complicated and you may decide that it is easier to
create multiple spec files, one per Linux distribution.
</para>
<para>
One way to help make vendor-specific packages, or to see which
RPM macros are defined on a given Linux distribution, is to look
for an RPM that contains the distribution-specific RPM
configuration. For example, on Red Hat Linux systems, the Red
Hat RPM configuration is defined by the redhat-rpm-config
package.
</para>
<para>
You can list the files in this package to see where Red Hat
defines macros specific to their Linux distribution.
</para>
<para>
$ rpm -ql redhat-rpm-config
</para>
<para>
/usr/lib/rpm/redhat
</para>
<para>
/usr/lib/rpm/redhat/brp-compress
</para>
<para>
/usr/lib/rpm/redhat/brp-redhat
</para>
<para>
/usr/lib/rpm/redhat/brp-sparc64-linux
</para>
<para>
/usr/lib/rpm/redhat/brp-strip
</para>
<para>
/usr/lib/rpm/redhat/brp-strip-comment-note
</para>
<para>
/usr/lib/rpm/redhat/brp-strip-shared
</para>
<para>
/usr/lib/rpm/redhat/find-lang.sh
</para>
<para>
/usr/lib/rpm/redhat/find-provides
</para>
<para>
/usr/lib/rpm/redhat/find-requires
</para>
<para>
/usr/lib/rpm/redhat/macros
</para>
<para>
/usr/lib/rpm/redhat/perl.prov
</para>
<para>
/usr/lib/rpm/redhat/perl.req
</para>
<para>
/usr/lib/rpm/redhat/rpmrc
</para>
<para>
These files, such as /usr/lib/rpm/redhat/macros, show you what
is specific to a given Linux distribution. You can then look at
the macros defined in these files to identify settings for a
particular distribution, in this case, Red Hat. Armed with this
knowledge, you can better create portable RPM spec files.
</para>
</sect2>
<sect2>
<title>Dealing with automatic dependency generation</title>
<para>
One of the features in RPM 4.x is the automatic generation of
dependencies. For a variety of reasons including different
package layouts, different directory structures, or different
versions of RPM, you may need to disable some or all of
automatic generation of dependencies.
</para>
<para>
You can disable the automatic generation of dependencies by
placing the following directive in your spec file:
</para>
<para>
Autoreq: 0
</para>
<para>
If you do so, you need to use the Requires: tag to manually
define all requirements. This is not a good solution to the
issue of automatic dependencies however. Most likely, you will
need to override the %{__find_requires} and %{__find_provides}
macros in order to filter out any unwanted dependencies.
</para>
<para>
These two macros resolve to shell scripts that perform the
automated dependency checks, as you can see with the rpm --eval
command:
</para>
<para>
$ rpm --eval "%__find_provides"
</para>
<para>
/usr/lib/rpm/find-provides
</para>
<para>
rpm --eval "%__find_requires"
</para>
<para>
/usr/lib/rpm/find-requires
</para>
<para>
You can override these scripts to filter out any dependencies
that cause problems for your packages.
</para>
</sect2>
<sect2>
<title>Dealing with different macros</title>
<para>
Different Linux vendors define different macros in their RPM
setup. This may mean not only different values for the macros,
but different macro names as well. Because of this, it is best
to define your own local set of macros when building RPMs.
</para>
<para>
As much as possible, depend on your own RPM macros. You can
define your macros in terms of vendor-specific macros using
conditional statements in your spec files, a topic covered in
Chapter 11. You can also read examples in the ���Build
Environment and Macros��� section of this chapter.
</para>
<para>
This really boils down to creating a disciplined RPM build
environment.
</para>
</sect2>
<sect2>
<title>Making relocatable packages</title>
<para>
You should aim to make your packages relocatable so that users
can install your packages into any directory. This makes it
easier to deal with the locations chosen by different Linux
distributions, such as /usr, /usr/local, or /opt, for installing
add-on software.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 10 covers the spec file format. Chapter 11 covers making
relocatable packages.
</para>
<para>
You can use the %{_bindir} macro in your spec files, which will
help create per-distribution packages using the right settings.
</para>
<para>
In addition, you can define macros in your spec files that
define the location for dependencies. You can then use the
--define option to the rpmbuild command to define values for
your macros that specify the locations for the dependencies.
</para>
<para>
Note
</para>
<para>
This technique of setting up Linux distribution-specific macros
can help solve a lot of problems with cross-platform RPMs.
</para>
</sect2>
<sect2>
<title>Creating an RPM build environment</title>
<para>
If you start with the idea that you want to build RPMs for
multiple versions of Linux, you can set up an RPM build
environment that cleanly separates most vendor-specific issues.
</para>
<para>
The key issues with the build environment are:
</para>
<para>
*Detecting the vendors
</para>
<para>
*Using macros to define a clean build process
</para>
<para>
*Handling different dependencies
</para>
<sect3>
<title>Detecting Vendors</title>
<para>
To make a clean build environment, you need to be able to
detect the Linux vendor and make build settings based on this
vendor. To help with this, many Linux vendors install a
special file with the vendor name, or a special package with
the vendor name. You can query for either of these.
</para>
<para>
For files, the convention follows:
</para>
<para>
/etc/vendor-release
</para>
<para>
For example:
</para>
<para>
$ more /etc/redhat-release
</para>
<para>
Red Hat Linux release 8.0 (Psyche)
</para>
<para>
For packages, the convention is vendor-release for a package
name. For example:
</para>
<para>
$ rpm -q redhat-release
</para>
<para>
redhat-release-8.0-8
</para>
<para>
You can use either approach or simply define a macro for the
vendor and use the --define option to set the macro. For
example:
</para>
<para>
# rpmbuild ���ba --define 'linuxVendor suse'
</para>
<para>
With this definition, you can use the macro %linuxVendor
inside your spec files. It is generally easier, though, if
your scripts can automatically detect the Linux vendor instead
of having to define it manually. The manual approach works,
though, if it becomes too much effort to detect the vendor
automatically.
</para>
</sect3>
<sect3>
<title>Build environment and macros</title>
<para>
Once you can detect the Linux vendor, you can create macros
based on the differences between Linux distributions that
affect your applications.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 21 covers RPM macros.
</para>
<para>
The macros that specifically help you with platform
differences include the %if .. %endif conditional. You can use
this in combination with special macros you define. In
addition, command-line options such as --with, --without, and
--target allow you to control features and the build target
within an RPM.
</para>
<para>
The %if macro allows you to specify a condition within your
spec file. For example:
</para>
<para>
%if %{old_5x} && %{old_6x}
</para>
<para>
%{error: You cannot build for .5x and .6x at the same time}
</para>
<para>
%quit
</para>
<para>
%endif
</para>
<para/>
<para>
%if %{old_5x}
</para>
<para>
%define b5x 1
</para>
<para>
%undefine b6x
</para>
<para>
%endif
</para>
<para/>
<para>
%if %{old_6x}
</para>
<para>
%define b6x 1
</para>
<para>
%undefine b5x
</para>
<para>
%endif
</para>
<para>
You can also use %if to control settings such as the
Requires:, as shown in the following example:
</para>
<para>
%if %{build6x}
</para>
<para>
Requires: util-linux, pam >= 0.66-5
</para>
<para>
%else
</para>
<para>
Requires: util-linux, pam >= 0.75-37,
/etc/pam.d/system-auth
</para>
<para>
%endif
</para>
<para/>
<para>
The --with command-line option defines a special macro
starting with _with_. For example, the following command-line
option defines a feature to use:
</para>
<para>
$ rpmbuild ���bc --with ssh filename.spec
</para>
<para>
This example defines the macro _with_ssh to --with-ssh. This
format was specially designed to work with GNU configure. You
can use this for conditional builds for platform-dependent
issues.
</para>
<para>
The --without command-line option similarly defines a macro
starting with _without_. The convention is that this option
defines a feature the code should not use.
</para>
<para>
You can combine --with and --without to turn on and off
features referenced in your spec files. For example:
</para>
<para>
./configure %{?_with_ssh}
</para>
<para>
This will pass the following command line if the _with_ssh
macro is defined:
</para>
<para>
./configure --with-ssh
</para>
<para>
If this option is not defined, the command will be:
</para>
<para>
./configure
</para>
<para>
The --target option sets the spec file macros %_target,
%_target_arch, and %_target_os . For example:
</para>
<para>
$ rpmbuild -bc --target ppc-ibm-aix
/usr/src/redhat/SPECS/jikes.spec
</para>
</sect3>
<sect3>
<title>Compatibility and Glue Packages</title>
<para>
Not all Linux distributions are the same. Macros alone won���t
provide work-arounds for all the differences. You can, though,
get a lot of mileage from compatibility and glue packages.
</para>
<para>
A compatibility package provides a legacy API on newer systems
that no longer support the legacy API. By convention,
compatibility packages are named with a leading compat- to
signify their purpose.
</para>
<para>
For example:
</para>
<para>
$ rpm -q --qf "%{description}" compat-libstdc++
</para>
<para>
The compat-libstdc++ package contains compatibility Standard
C++
</para>
<para>
Using a compatibility package allows you to create programs
that use a least-common-denominator approach, programming to
the oldest but most common APIs. As some Linux distributions
eliminate the old APIs, compatibility packages can provide the
missing APIs.
</para>
<para>
Similarly, a glue package provides a dependency that exists on
some Linux distributions but not others. It glues together
your package with the Linux distribution that is missing an
essential capability.
</para>
<para>
Note
</para>
<para>
A key point in both of these approaches is to separate the
compatibility and glue packages from your main application
packages. The application packages should be as clean of
vendor issues as possible. Instruct your users to install the
compatibility or glue packages as needed (based on their Linux
distribution) along with the main application package or
packages.
</para>
<para>
With all this discussion of RPM and Linux differences, you
might think that Linux is one big mess. That���s not true.
Linux maintains a high degree of compatibility among Linux
distributions as well as among processor architectures. Most
programs originally created for Linux on Intel-based
architectures compile cleanly on Linux versions running on
other processor architectures such as MIPS, SPARC, and ARM.
</para>
<para>
The main differences lie in how Linux vendors split up the
huge number of files associated with Linux into RPM packages
as well as which versions of tools like C compilers the
vendors ship.
</para>
</sect3>
<sect3>
<title>Dealing with Signatures</title>
<para>
With SuSE Linux, or any Linux based on UnitedLinux 1.0, the
RPM packages are signed with OpenPGP version 4, not 3, as used
in RPM 4.1. This means that you must use some other, non-RPM
means to extract the signatures from an RPM package, and then
verify these signatures with gpg.
</para>
<para/>
</sect3>
</sect2>
</sect1>
<sect1>
<title>Dealing with Non-RPM-Based Linux Versions</title>
<para>
The main Linux distributions that don���t support RPM are the
Debian GNU/Linux family and Slackware Linux. To help with these
distributions, you can use a package-conversion tool called alien.
</para>
<sect2>
<title/>
</sect2>
<sect2>
<title>Handling non-RPM packages with alien</title>
<para>
Alien is a package that supports conversions between RPM and
so-called alien package formats such as the dpkg (Debian
GNU/Linux), slp (Stampede Linux), and tgz (Slackware Linux)
formats.
</para>
<para>
You can use alien on your RPM-based Linux system to convert RPMs
to some other format, such as the Debian dpkg. You can also use
alien to convert other package formats into RPMs, depending on
which way you need to go.
</para>
<para/>
<para/>
</sect2>
</sect1>
<sect1>
<title>Standardizing RPMs</title>
<para>
RPM is being considered as part of the Linux Standard Base, or
LSB, 1.3. This will define a standard packaging format for Linux
distributions, and over time reduce the RPM differences between
distributions.
</para>
<para>
In addition, other efforts are underway to help unify the diverse
Linux distributions, including the Filesystem Hierarchy Standard
and the adoption of RPM by many Linux vendors.
</para>
<sect2>
<title>Filesystem Hierarchy Standard</title>
<para>
The FHS, or Filesystem Hierarchy Standard, defines the purpose
of all the upper-level directories on Linux systems, such as
/var and /usr/bin. This standard, along with the Linux Standard
Base, or LSB, is driving Linux distributions to a greater degree
of similarity.
</para>
<para>
The FHS helps by specifying where applications should get
installed and which directories should be left to local
administrators to manage. The FHS also defines the purpose of
all Linux directories, giving vendors and application writers a
better idea of where they should install their packages.
</para>
<para>
Cross Reference
</para>
<para>
See www.linuxbase.org for more on the LSB. See
www.pathname.com/fhs/ for more on the FHS.
</para>
</sect2>
<sect2>
<title>RPM adoption</title>
<para>
RPM has been adopted by a large number of Linux distributions.
In addition, standardization efforts, both for RPM and for
filesystem locations, are making Linux systems less varied.
</para>
<para>
This means that over time, many of the RPM-related differences
between Linux distributions will fade away, making it easier to
create cross-platform RPMs.
</para>
<para/>
<para/>
</sect2>
</sect1>
<sect1>
<title>Summary</title>
<para>
This chapter covers differences in RPM versions between various
Linux distributions, and techniques you can use to get around
these differences. Each Linux vendor packages software
differently, even if the vendor uses RPM. This can cause problems
unless you write your spec files carefully.
</para>
<para>
Inside your RPM spec files, you can use conditional elements as
well as platform-based macro definitions to help create RPMs for
multiple packages.
</para>
<para>
Some of the best conventions are to split the software in your
applications from any compatibility or glue packages, separate
packages that provide missing features for various flavors of
Linux.
</para>
<para>
Standardization efforts such as the Linux Standard Base and
Filesystem Hierarchy Standard are bringing Linux vendors closer
and closer together. Widespread adoption of RPM by most Linux
distributions also helps.
</para>
<para>
While this chapter covers RPM on other Linux distributions, the
next chapter tackles RPM outside of Linux.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-online-resources-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv715
Added Files:
rpm-guide-online-resources-en.xml
Log Message:
--- NEW FILE rpm-guide-online-resources-en.xml ---
<!-- $Id: -->
<chapter id="ch-online-resources">
<title>RPM Resources</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Appendix
</para>
<para>
*Finding RPM sites on the Internet
</para>
<para>
*Accessing RPM newsgroups and mailing lists
</para>
<para>
This appendix covers the material available on the Internet for
working with RPM.
</para>
<sect1>
<title>Finding RPM Sites</title>
<para>
There is a wealth of RPM material online, although some of it is
hard to find. The following sections list a number of RPM-related
sites, divided by category. Note that as with any Internet sites,
the sites listed my change or disappear.
</para>
<sect2>
<title>The main rpm.org site</title>
<para>
The main RPM site is www.rpm.org. This site provides the
official distributions of the RPM software, as well as a lot of
documentation online.
</para>
<para>
Table F-1 lists a number of useful links on this site.
</para>
<para>
Table F-1 Links on the rpm.org site
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Link
</para>
</entry>
<entry>
<para>
Holds
</para>
</entry>
</row>
<row>
<entry>
<para>
ftp://ftp.rpm.org/pub/rpm/dist/
</para>
</entry>
<entry>
<para>
RPM software downloads
</para>
</entry>
</row>
<row>
<entry>
<para>
ftp://ftp.rpm.org/pub/
</para>
</entry>
<entry>
<para>
rpm.org download site
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/cvs_help/
</para>
</entry>
<entry>
<para>
Instructions for accessing the RPM CVS repository
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/hintskinks/
</para>
</entry>
<entry>
<para>
Tips for working with RPM
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/hintskinks/bootstrap/
</para>
</entry>
<entry>
<para>
Good tips on bootstrapping RPM to new platforms
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/howto/
</para>
</entry>
<entry>
<para>
How-to documents for working with RPM
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/max-rpm/
</para>
</entry>
<entry>
<para>
Maximum RPM by Edward C. Bailey
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/RPM-HOWTO/
</para>
</entry>
<entry>
<para>
Good introductory tutorial
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/rpmapi-4.1/
</para>
</entry>
<entry>
<para>
API documentation
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
The main RPM FTP site, at ftp://ftp.rpm.org/pub/, includes the
RPM distributions, as well as the Berkeley DB version 3 library,
and the text of the book Maximum RPM. Download RPM software from
ftp://ftp.rpm.org/pub/rpm/dist/.
</para>
</sect2>
<sect2>
<title>RPM locator sites</title>
<para>
A number of sites help you find RPMs for various applications.
On the main sites, you can find specially built RPMs for a
variety of Linux distributions. You can then download the RPMs
made especially for your systems.
</para>
<para>
The main RPM-finding site is rpmfind.net, which offers a search
engine as well as software you can run on your site.
</para>
<para>
The RPM PBone Search, at http://rpm.pbone.net/, is also very
useful.
</para>
<para>
The www.rpm.org/packagers/ site lists a number of places that
package RPMs and provide them for downloading.
</para>
<para>
Many Java libraries and packages are available in RPM format
from www.jpackage.org/.
</para>
<para>
Table F-2 lists a number of other RPM download sites.
</para>
<para>
Table F-2 RPM download sites
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Site
</para>
</entry>
<entry>
<para>
Holds
</para>
</entry>
</row>
<row>
<entry>
<para>
rpmfind.net
</para>
</entry>
<entry>
<para>
Links to a huge number of RPMs, many specific to
various Linux distributions
</para>
</entry>
</row>
<row>
<entry>
<para>
http://rpm.pbone.net/
</para>
</entry>
<entry>
<para>
RPM PBone search, useful for finding RPMs
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpm.org/packagers/
</para>
</entry>
<entry>
<para>
Lists a number of sites that provide RPMs for download
</para>
</entry>
</row>
<row>
<entry>
<para>
www.javapackage.org
</para>
</entry>
<entry>
<para>
Many Java packages in RPM format
</para>
</entry>
</row>
<row>
<entry>
<para>
http://plf.zarb.org/
</para>
</entry>
<entry>
<para>
The Penguin Liberation Front has RPMs that for legal
reasons cannot be included in the Mandrake Linux
distribution.
</para>
</entry>
</row>
<row>
<entry>
<para>
www.math.unl.edu/~rdieter/Projects
</para>
</entry>
<entry>
<para>
Rex Dieter���s RPM site
</para>
</entry>
</row>
<row>
<entry>
<para>
www.rpmhelp.net
</para>
</entry>
<entry>
<para>
Mandrake Linux RPMs
</para>
</entry>
</row>
<row>
<entry>
<para>
www.aucs.org/rpmcenter/
</para>
</entry>
<entry>
<para>
Edwin Chan's Red Hat RPMs
</para>
</entry>
</row>
<row>
<entry>
<para>
www.owlriver.com/projects/links/
</para>
</entry>
<entry>
<para>
Owl River Company RPMs
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>RPM tools sites</title>
<para>
A large number of tools exist to help you work with RPMs. The
following sites list some of the main tools:
</para>
<para>
*For the vim text editor, you can download a spec.vim syntax
file from
http://pegasus.rutgers.edu/~elflord/vim/syntax/spec.vim.
</para>
<para>
*For emacs, you can download an Emacs mode for spec files from
http://tihlde.org/~stigb/rpm-spec-mode.el.
</para>
<para>
Cross Reference
</para>
<para>
Appendix F lists links for a number of text editors.
</para>
<para>
*The rpmlint tool mentioned in Chapter 13 is available at
http://people.mandrakesoft.com/~flepied/projects/rpmlint/.
</para>
<para>
Table F-3 lists a number of RPM-related tools and the sites you
can find more information on the tools.
</para>
<para>
Table F-3 RPM-related tools
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Tool
</para>
</entry>
<entry>
<para>
Site
</para>
</entry>
</row>
<row>
<entry>
<para>
apt-rpm
</para>
</entry>
<entry>
<para>
ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/
</para>
</entry>
</row>
<row>
<entry>
<para>
apt4rpm
</para>
</entry>
<entry>
<para>
http://apt4rpm.sourceforge.net/
</para>
</entry>
</row>
<row>
<entry>
<para>
AutoRPM
</para>
</entry>
<entry>
<para>
www.autorpm.org
</para>
</entry>
</row>
<row>
<entry>
<para>
AutoUpdate
</para>
</entry>
<entry>
<para>
www.mat.univie.ac.at/~gerald/ftp/autoupdate
</para>
</entry>
</row>
<row>
<entry>
<para>
current
</para>
</entry>
<entry>
<para>
www.biology.duke.edu/computer/unix/current/
</para>
</entry>
</row>
<row>
<entry>
<para>
kpackage
</para>
</entry>
<entry>
<para>
www.kde.org
</para>
</entry>
</row>
<row>
<entry>
<para>
MakeRPM.pl
</para>
</entry>
<entry>
<para>
www.perl.com/CPAN/modules/by-authors/id/JWIED
</para>
</entry>
</row>
<row>
<entry>
<para>
poldek
</para>
</entry>
<entry>
<para>
http://poldek.pld.org.pl/
</para>
</entry>
</row>
<row>
<entry>
<para>
rpm2html
</para>
</entry>
<entry>
<para>
rpmfind.net/linux/rpm2html/
</para>
</entry>
</row>
<row>
<entry>
<para>
rpmfind
</para>
</entry>
<entry>
<para>
rpmfind.net
</para>
</entry>
</row>
<row>
<entry>
<para>
RUST
</para>
</entry>
<entry>
<para>
www.rusthq.com
</para>
</entry>
</row>
<row>
<entry>
<para>
setup.sh
</para>
</entry>
<entry>
<para>
www.mmedia.is/~bre/programs/setup.sh
</para>
</entry>
</row>
<row>
<entry>
<para>
urpmi
</para>
</entry>
<entry>
<para>
www.linux-mandrake.com/cooker/urpmi.html
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>Programming sites</title>
<para>
Only a few sites exist to help developers with programming for
RPM. I maintain some quick links to RPM sites at
www.pconline.com/~erc/rpm.htm. Most of these links are focused
for programming with RPM.
</para>
<para>
The best sites for programming RPM are the online API
documentation at www.rpm.org/rpmapi-4.1/ for the RPM 4.1
release, and the ftp.rpm.org/pub/rpm/dist/ site for downloading
the RPM sources. There is a lot of documentation bundled with
the source code.
</para>
<para>
Cross Reference
</para>
<para>
Appendix F lists links for a number of Integrated Development
Environments, or IDEs, aimed at programmers.
</para>
</sect2>
<sect2>
<title>Sites related to RPM</title>
<para>
If you try to make cross-platform RPMs, especially RPMs that
should work for multiple versions of Linux, it is very important
to follow the Linux standards for things like file placement and
package formats.
</para>
<para>
The Filesystem Hierarchy Standard, or FHS, covers Linux
directory layout at www.pathname.com/fhs/.
</para>
<para>
The Linux Standards Base is working on standardizing on the RPM
package file format. See www.linuxbase.org for details.
</para>
</sect2>
</sect1>
<sect1>
<title>Accessing RPM Mailing Lists and Newsgroups</title>
<para>
The RPM mailing list provides the best source of technical RPM
information. You can post questions and get quick, useful
responses. If you are working with RPM, you should subscribe to
this mailing list. For details on viewing the RPM mailing list
archives and signing up for the list, see
www.rpm.org/mailing_list/.
</para>
<para>
To help avoid unwanted commercial e-mail (in other words, spam),
you need to register with a user name and password to subscribe to
the mailing list or view the archives.
</para>
<para>
A Usenet newsgroup, named linux.redhat.rpm, also provides a forum
for asking RPM-related questions. You can read this newsgroup with
any newsreading program.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-management-software-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv681
Added Files:
rpm-guide-management-software-en.xml
Log Message:
--- NEW FILE rpm-guide-management-software-en.xml ---
<!-- $Id: -->
<chapter id="ch-management-software">
<title>RPM Management Software</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Finding packages in RPM format
</para>
<para>
*Graphical tools to manage RPM packages
</para>
<para>
*Extending RPM management with additional tools
</para>
<para>
You can find a variety of software packages to ease the work of
managing RPM-based systems. These utilities can help you find a
specific software application packaged using RPM or search through a
collection of RPM-packaged software to locate applications with
specific features. Similarly, several utilities provide features to
ease long-term system-management tasks. These applications provide
features such as automatic updating of existing installed software
with more recent versions or simplification of software installation
by automating installation of any required software dependencies.
</para>
<para>
This chapter covers a number of tools for finding packages in RPM
format, as well as tools to help manage the RPMs on your system.
</para>
<sect1>
<title>Locating RPMs</title>
<para>
RPM provides a powerful tool for managing software installed on a
system. With a single command, an entire application can be
installed on the system in a ready-to-run configuration. With a
different command, the entire application can be removed without
having manually to track down all of the associated files
scattered throughout the hard drive. For RPM to work, however, the
software being managed must be packaged in the proper RPM format.
RPM packages can be easily prepared if necessary, but you can save
time by using the wide variety of software already available in
the RPM format. The only trick to using this RPM-packaged software
is finding it.
</para>
<para>
As you start to search for RPM packages on the Internet, you���ll
find thousands of packages available. Many of these packages are
built specifically for various Linux distributions, such as
Conectiva, SuSE, Red Hat, or Mandrake. In many cases, the Linux
distribution won���t matter, but in general it's best to download
packages built for your version of Linux, such as Red Hat.
</para>
<para>
Note
</para>
<para>
Although the examples in this book assume Red Hat Linux as a base,
just about everything applies to all versions of Linux that use
the RPM system, unless noted otherwise.
</para>
<para>
Internet search engines are popular, but they aren���t very
helpful for finding RPM packages, especially because lots of Web
pages have the term rpm (including those covering revolutions per
minute). A more efficient approach is to use one of the
RPM-specific Internet search tools such as rpmfind.
</para>
<sect2>
<title>rpmfind and rpm2html</title>
<para>
One popular free tool for locating RPMs is rpmfind, written by
Daniel Veillard. This tool provides a command-line utility that
can search for packages by name or description, displaying or
optionally downloading any matching packages it finds. It can
even provide a list of the dependencies that those matching
packages require to run and can download those required
dependencies as well.
</para>
<para>
When searching for packages, rpmfind can search both the
software already installed on the local system and remote
databases, including the databases located at
http://rpmfind.net/.
</para>
<para>
Note
</para>
<para>
The databases at http://rpmfind.net/ are, in turn, created by
another utility: rpm2html. Both are covered in the sections
following.
</para>
<para>
Commonly, rpmfind is used to search for packages by name, though
it can be used to search package descriptions for key words. For
example, I might want to find new e-mail clients to install on
my system. I happen to know that one popular Linux e-mail client
is Ximian���s evolution, so I search for that.
</para>
<para>
The basic syntax for rpmfind follows:
</para>
<para>
rpmfind package_name
</para>
<para>
For example, to search for evolution, use a command like the
following:
</para>
<para>
$ rpmfind evolution
</para>
<para>
Resource evolution already installed
</para>
<para>
$
</para>
<para>
Before accessing the Internet, rpmfind searches my local system
and finds that I already have evolution installed, so it does
not even bother searching for copies to download. It looks like
I���m forgetful, not remembering that I already have evolution
installed. At this point, I might realize that I already have
the software I need, or I might decide to search for a similar
application, such as exmh, another popular Unix e-mail client.
</para>
<para>
To search for exmh (which in this example has not been
installed), use a command like the following:
</para>
<para>
$ rpmfind exmh
</para>
<para>
Installing exmh will require 7301 KBytes
</para>
<para/>
<para>
### To Transfer:
</para>
<para>
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0...
</para>
<para>
86.rpm
</para>
<para>
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2....
</para>
<para>
Do you want to download these files to /tmp [Y/n/a/i] ? : a
</para>
<para>
transferring
</para>
<para>
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0...
</para>
<para>
saving to /tmp/nmh-1.0.4-9.i386.rpm
</para>
<para>
transferring
</para>
<para>
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2....
</para>
<para>
saving to /tmp/exmh-2.4-2.noarch.rpm
</para>
<para>
rpm -U /tmp/nmh-1.0.4-9.i386.rpm /tmp/exmh-2.4-2.noarch.rpm
</para>
<para>
$
</para>
<para>
Here, rpmfind searches my local system for exmh. Since exmh is
not installed there, rpmfind searches the databases at
http://rpmfind.net/ and does two things: it finds exmh, and it
learns that exmh depends upon another package: nmh. After
[...1729 lines suppressed...]
this reason, apt can only be used to update systems from
apt-capable repositories.
</para>
<para>
Although apt was created by the Debian Project and designed for
dpkg-format software packages, nothing about apt requires that
it inherently be usable only with dpkg-format packages. Because
of this, and because of its powerful capabilities, Conectiva, a
Brazilian Linux distribution vendor (www.conectiva.com),
extended apt to support management of RPM packages in addition
to dpkg packages. Conectiva���s work, commonly referred to as
apt-rpm, makes the apt client software available for use on any
RPM-based Linux distribution. Conectiva also provides its
customers with access to apt-capable FTP servers. A related
project, apt4rpm (http://apt4rpm.sourceforge.net/), supplies the
necessary utilities that can be used to make any RPM repository
apt-capable. By creating apt-capable servers using apt4rpm and
then installing apt-rpm on the client systems, any RPM-based
distribution, such as Red Hat Linux, Mandrake Linux, Caldera/SCO
OpenLinux, or SuSE Linux, can then be easily managed using apt.
</para>
<para>
Note
</para>
<para>
The freshrpms.net site, mentioned previously, provides a touted
apt repository.
</para>
<para>
Administrators managing multiple dispersed machines as well as
those used to Debian administration often find it useful to
configure their machines to use apt; its dependency tracking is
far better than any other tool, except for Red Hat���s
up2date/RHN combination. To use apt, administrators must install
it on their machines and have access to an apt-capable RPM
repository for the distribution they use. Several public FTP
sites that support apt are now available for most of the major
RPM-based distributions. Also, the administrator can create
another apt-capable repository.
</para>
<para>
Configuration of machines to use apt is simple. The apt and
libapt RPMs simply need to be installed. Although binaries are
sometimes available, the best success can usually be obtained by
building binary RPMs from the latest Conectiva apt SRPM (source
RPM), available at
ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/.
</para>
<para>
Once apt and libapt RPMs are installed, the sources.list file in
/etc/apt needs to be modified to reference the apt-capable
software site that will be used. For example, to configure a
machine to access the apt-capable Red Hat Linux 7.2 software
distributed by the Tuxfamily.org server, the
/etc/apt/sources.list file needs to list:
</para>
<para>
rpm http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os
</para>
<para>
rpm http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat
os
</para>
<para>
These two lines, respectively, access the Red Hat Linux 7.2 and
Red Hat Linux 7.2 errata RPMs being served by the system
apt-rpm.tuxfamily.org. If you also want access to source RPMs,
the following lines are necessary as well.
</para>
<para>
rpm-src http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat
os
</para>
<para>
rpm-src http://apt-rpm.tuxfamily.org/apt
redhat-updates-7.2/redhat os
</para>
<para>
In addition to, or instead of, using public apt-capable servers,
many sites want to create their own apt servers. If apt is being
used to manage all the machines in the enterprise, a custom apt
server might be needed that contains apt-accessible RPMs of all
the custom software used in the enterprise. This can be done
using the tools provided by the apt4rpm package
(http://apt4rpm.sourceforge.net).
</para>
<para>
Once apt has been installed on clients, and the clients have
been configured to access an apt-capable server, keeping systems
updated is simple. The command apt-get update updates the client
system���s apt database of available software, after which the
command apt-get upgrade upgrades all currently installed
software to the latest version available in the software
repository. By listing a site that provides vendor errata
updates in /etc/apt/sources.list and then setting up a nightly
cron job to run the apt-get upgrade command, administrators can
be sure that client systems always have the latest errata
installed. You can use a similar technique to ensure that all
client systems are always up to date with the latest custom
in-house applications. To do this, set up your own apt server
and ensure that the latest custom applications are placed on the
apt server.
</para>
<para>
In addition, apt simplifies interactive installation of RPMs on
systems that are using it. The command apt-get install package
retrieves the named RPM from the apt-capable software repository
and installs it. If the package requires any dependencies that
are not already resolved, apt will ask for confirmation, then
download and install the package and all dependencies.
Similarly, apt-get remove package uninstalls the named RPM. If
any other packages depend on it, it will prompt for
confirmation, then uninstall the named RPM and all of its
dependencies.
</para>
<para>
In addition to these command-line utilities, several graphical
front-end tools for manipulating apt are currently being ported
for use with apt-rpm. Because of its ease of use for automating
installation of system errata and necessary custom software, and
because of the excellent dependency tracking it provides for
interactive installation and uninstallation of software, apt-rpm
can be excellent for managing RPM-based systems.
</para>
</sect2>
<sect2>
<title>The poldek</title>
<para>
Also similar to the Debian apt tool, a utility called the poldek
works like apt-get. The poldek was designed to quickly scan
through dependencies and install a number of packages at once.
You can specify all the packages to install in a file.
</para>
<para>
The poldek automatically downloads any needed dependencies. The
poldek can download files over the Internet and also help create
the packages for storage on CD-ROMs. The poldek optimizes the
set of packages to reduce the number of times users have to
switch CDs.
</para>
<para>
Cross Reference
</para>
<para>
For more on the poldek, see poldek.pld.org.pl.
</para>
</sect2>
</sect1>
<sect1>
<title>Summary</title>
<para>
This chapter has covered a number of tools for finding packages in
RPM format, as well as tools to help manage the RPMs on your
system. The rpm command does a great job of installing, removing,
and upgrading packages. You can use it or choose from one of the
many graphical RPM management tools shown in this chapter.
</para>
<para>
The rpmfind utility helps find RPM packages on Internet servers.
You can use rpmfind to find the latest version of the packages
installed on your system.
</para>
<para>
The Nautilus file manager allows you to browse files on disk, and
it installs any RPM files you double-click.
</para>
<para>
Red Hat Linux 8 comes with a new package-management tool available
from the System Settings menu. Be careful with this tool, though,
as it automatically installs--and removes--dependent packages.
</para>
<para>
AutoRPM and AutoUpdate provide utilites that you can run
periodically to ensure that your systems are up to date. The Red
Hat Network and up2date also provides this capability.
</para>
<para>
The Debian GNU/Linux apt system provides many of the same
capabilities as RPM, along with the network-updating capabilities
of up2date and the Red Hat Network. You can use special apt
packages that adapt apt for RPM-based Linux distributions and get
the best of both the RPM system and the apt system.
</para>
<para>
The next chapter starts the major section on creating RPMs. The
RPM system reduces a lot of the burden of administering Linux
systems. You can take advantage of this when building any sort of
software for distribution--or even when managing your own system.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-licensing-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv651
Added Files:
rpm-guide-licensing-en.xml
Log Message:
--- NEW FILE rpm-guide-licensing-en.xml ---
<!-- $Id: -->
<chapter id="ch-licensing">
<title>Licensing RPM</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
When incorporating someone else's existing code into your software
project, you should always examine the license of the code
carefully, make sure you understand its implications, and make sure
you are willing to abide by them. You also need to make sure you
have the legal right to incorporate the other code in your project.
This is true for commercial code and commercial projects, and it is
equally true for freely licensed code and free software projects.
</para>
<para>
RPM itself and most discussed helper applications (rpmlint,
rpm-spec-mode, and so forth) are free software, meaning that the
programs themselves are available without cost. In addition, most of
these tools are considered open source software, which means the
source code for the applications are also available.
</para>
<para>
These facts do not mean that they are unlicensed software, or that
their source code can be used in any desired fashion. RPM and these
helper applications are made freely available in both source and
binary formats under the terms of the GNU Project's General Public
License (GPL). Parts of RPM are licensed under the LGPL, the Lesser
General Public License. The terms of the GPL are reproduced here,
and should be consulted before incorporating any source code or
binaries licensed under the GPL into your projects. Essentially, the
GPL states that you can use GPL'ed source code or binaries for any
purpose, so long as you always give those same rights (including
access to your program���s source code) to any users to whom you
give software derived from GPL'ed source code (though a lawyer
should be consulted to obtain an analysis of the implications of the
GPL on your project, should you decide to use GPL'ed code in any
commercially licensed project you might undertake).
</para>
<para/>
<sect1>
<title>The GNU General Public License</title>
<para>
Version 2, June 1991
</para>
<para/>
<para>
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
</para>
<para>
675 Mass Ave, Cambridge, MA 02139, USA
</para>
<para>
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.
</para>
<para/>
<para>
Preamble
</para>
<para>
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General
Public License is intended to guarantee your freedom to share and
change free software--to make sure the software is free for all
its users. This General Public License applies to most of the Free
Software Foundation's software and to any other program whose
authors commit to using it. (Some other Free Software Foundation
software is covered by the GNU Library General Public License
instead.) You can apply it to your programs, too.
</para>
<para/>
<para>
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and
charge for this service if you wish), that you receive source code
or can get it if you want it, that you can change the software or
use pieces of it in new free programs; and that you know you can
do these things.
</para>
<para/>
<para>
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the
rights. These restrictions translate to certain responsibilities
for you if you distribute copies of the software, or if you modify
it.
</para>
<para/>
<para>
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights
that you have. You must make sure that they, too, receive or can
get the source code. And you must show them these terms so they
know their rights.
</para>
<para/>
<para>
We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to
copy, distribute and/or modify the software.
</para>
<para/>
<para>
Also, for each author's protection and ours, we want to make
certain that everyone understands that there is no warranty for
this free software. If the software is modified by someone else
and passed on, we want its recipients to know that what they have
is not the original, so that any problems introduced by others
will not reflect on the original authors' reputations.
</para>
<para/>
<para>
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making
the program proprietary. To prevent this, we have made it clear
that any patent must be licensed for everyone's free use or not
licensed at all.
</para>
<para/>
<para>
The precise terms and conditions for copying, distribution and
modification follow.
</para>
<para/>
<para>
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
</para>
<para>
0.This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be
distributed under the terms of this General Public License. The
"Program", below, refers to any such program or work, and a "work
based on the Program" means either the Program or any derivative
work under copyright law: that is to say, a work containing the
Program or a portion of it, either verbatim or with modifications
and/or translated into another language. (Hereinafter, translation
is included without limitation in the term "modification".) Each
licensee is addressed as "you".
</para>
<para>
Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The act
of running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the
Program). Whether that is true depends on what the Program does.
</para>
<para>
1.You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep
intact all the notices that refer to this License and to the
absence of any warranty; and give any other recipients of the
Program a copy of this License along with the Program.
</para>
<para>
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange
for a fee.
</para>
<para>
2.You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
</para>
<para>
a)You must cause the modified files to carry prominent notice
stating that you changed the files and the date of any change.
</para>
<para>
b)You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
</para>
<para>
c)If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but does
not normally print such an announcement, your work based on the
Program is not required to print an announcement.)
</para>
<para>
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works. But when you distribute the same sections as part of a
whole which is a work based on the Program, the distribution of
the whole must be on the terms of this License, whose permissions
for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.
</para>
<para>
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program.
</para>
<para>
In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on
a volume of a storage or distribution medium does not bring the
other work under the scope of this License.
</para>
<para>
3.You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you also do one of the
following:
</para>
<para>
a)Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software
interchange; or,
</para>
<para>
b)Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
</para>
<para>
c)Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
</para>
<para>
The source code for a work means the preferred form of the work
for making modifications to it. For an executable work, complete
source code means all the source code for all modules it contains,
plus any associated interface definition files, plus the scripts
used to control compilation and installation of the executable.
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either
source or binary form) with the major components (compiler,
kernel, and so on) of the operating system on which the executable
runs, unless that component itself accompanies the executable.
</para>
<para>
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
</para>
<para>
4.You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights,
from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
</para>
<para>
5.You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify
or distribute the Program or its derivative works. These actions
are prohibited by law if you do not accept this License.
Therefore, by modifying or distributing the Program (or any work
based on the Program), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on it.
</para>
<para>
6.Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program
subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing compliance
by third parties to this License.
</para>
<para>
7.If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent
obligations, then as a consequence you may not distribute the
Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only
way you could satisfy both it and this License would be to refrain
entirely from distribution of the Program.
</para>
<para>
If any portion of this section is held invalid or unenforceable
under any particular circumstance, the balance of the section is
intended to apply and the section as a whole is intended to apply
in other circumstances.
</para>
<para>
It is not the purpose of this section to induce you to infringe
any patents or other property right claims or to contest validity
of any such claims; this section has the sole purpose of
protecting the integrity of the free software distribution system,
which is implemented by public license practices. Many people have
made generous contributions to the wide range of software
distributed through that system in reliance on consistent
application of that system; it is up to the author/donor to decide
if he or she is willing to distribute software through any other
system and a licensee cannot impose that choice.
</para>
<para>
This section is intended to make thoroughly clear what is believed
to be a consequence of the rest of this License.
</para>
<para>
8.If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces,
the original copyright holder who places the Program under this
License may add an explicit geographical distribution limitation
excluding those countries, so that distribution is permitted only
in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of
this License.
</para>
<para>
9.The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
</para>
<para>
Each version is given a distinguishing version number. If the
Program specifies a version number of this License which applies
to it and "any later version", you have the option of following
the terms and conditions either of that version or of any later
version published by the Free Software Foundation. If the Program
does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.
</para>
<para>
10.If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted by
the Free Software Foundation, write to the Free Software
Foundation; we sometimes make exceptions for this. Our decision
will be guided by the two goals of preserving the free status of
all derivatives of our free software and of promoting the sharing
and reuse of software generally.
</para>
<para>
NO WARRANTY
</para>
<para>
11.BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS
AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR
OR CORRECTION.
</para>
<para>
12.IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
</para>
<para>
END OF TERMS AND CONDITIONS
</para>
<para/>
<para>
Appendix: How to Apply These Terms to Your New Programs
</para>
<para/>
<para>
If you develop a new program, and you want it to be of the
greatest possible use to the public, the best way to achieve this
is to make it free software which everyone can redistribute and
change under these terms.
</para>
<para/>
<para>
To do so, attach the following notices to the program. It is
safest to attach them to the start of each source file to most
effectively convey the exclusion of warranty; and each file should
have at least the "copyright" line and a pointer to where the full
notice is found.
</para>
<para>
<one line to give the program's name and a brief idea of what
it does.> Copyright (C) 19yy <name of author>
</para>
<para>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
</para>
<para>
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
</para>
<para>
Also add information on how to contact you by electronic and paper
mail.
</para>
<para/>
<para>
If the program is interactive, make it output a short notice like
this when it starts in an interactive mode:
</para>
<para>
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type
`show w'. This is free software, and you are welcome to
redistribute it under certain conditions; type `show c' for
details.
</para>
<para/>
<para>
The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and
`show c'; they could even be mouse-clicks or menu items--whatever
suits your program.
</para>
<para/>
<para>
You should also get your employer (if you work as a programmer) or
your school, if any, to sign a "copyright disclaimer" for the
program, if necessary. Here is a sample; alter the names:
</para>
<para>
Yoyodyne, Inc., hereby disclaims all copyright interest in the
program `Gnomovision' (which makes passes at compilers) written by
James Hacker.
</para>
<para>
<signature of Ty Coon>, 1 April 1989Ty Coon, President of
Vice
</para>
<para>
This General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking
proprietary applications with the library. If this is what you
want to do, use the GNU Library General Public License instead of
this License.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-intro-rpm-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv622
Added Files:
rpm-guide-intro-rpm-en.xml
Log Message:
--- NEW FILE rpm-guide-intro-rpm-en.xml ---
<!-- $Id: -->
<chapter id="ch-intro-rpm">
<title>Introduction to RPM</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Examining the history of package management
</para>
<para>
*Introducing RPM features
</para>
<para>
*Getting acquainted with RPM terminology
</para>
<para>
Several package managers���software that tracks and manipulates the
applications installed on the system���are available for Linux. The
most widely used of these Linux package managers is the RPM Package
Manager (formerly the Red Hat Package Manager), or RPM for short,
the subject of this book
</para>
<para>
Although RPM was initially developed for Red Hat Linux, a
combination of technical features and good timing has resulted in
RPM���s becoming the de facto standard for packaging software on
most Linux distributions. The fact that Red Hat released the source
code to the RPM software under an open-source license also helped
its adoption.
</para>
<para>
More recently, the RPM package file format has been adopted as the
official standard for Linux as part of the Linux Standards Base, or
LSB. Described at www.linuxbase.org/, the Linux Standards Base is an
attempt to set a baseline that all Linux distributions should
follow. Some vendors have been pulled in kicking and screaming, but
the LSB for the most part has really helped the job of system
administrators by providing some commonality across distributions,
as in the location of certain files. The history of Linux package
managers is largely intertwined with the history of Linux
distributions.
</para>
<para>
Strictly speaking, Linux refers to a single piece of software, the
Unix-like kernel that Linus Torvalds and cohorts have scattered all
over the Internet and have been developing since 1991. This Linux
kernel is a marvelous piece of software, currently comprising over
3.7 million lines of freely-licensed source code and accompanying
documentation. Together, these factors provide a fast,
full-featured, stable operating system kernel for use on more than
30 different processor architectures, ranging from embedded systems
such as watches and PDAs, to desktop and server systems, all the way
up to mainframes and supercomputing clusters.
</para>
<sect1>
<title>The Need for Linux Package Management Systems</title>
<para>
Although Linux is an excellent core component of an operating
system suitable for a wide variety of real-world applications,
this Linux kernel by itself is not sufficient for accomplishing
most tasks. The technical definition of exactly what constitutes
an operating system is a matter of debate.
</para>
<para>
Despite this controversy, it is clear that most users of Linux
require both the Linux kernel and a large suite of accompanying
software (a shared C library; traditional Unix utilities such as
grep, awk, and sed; an editor, such as vi; a shell, such as the
Bourne-Again "bash" shell; and so forth) to complete the various
tasks for which they typically employ Linux.
</para>
<para>
Users expect Linux to include server software such as the Apache
Web server, desktop software such as the OpenOffice.org office
productivity suite, and a host of other packages. In fact, most
Linux users don���t make the distinction between the kernel
(technically the only part that is ���Linux���) and all the extra
packages (technically ���everything else���) that comes with a
Linux distribution. Most users simply refer to the whole thing as
���Linux.���
</para>
<para>
Some Linux distributions include thousands of packages on six or
more CD-ROMs. This situation alone cries out for effective
package-management software. And this doesn���t include the extra
packages that don���t come with Linux distributions but which
organizations need to create an effective working environment.
</para>
<para>
Furthermore, the Linux kernel and these various software
applications are typically made available by their developers in
source code formats only, and they can be installed manually only
after compiling them from source code.
</para>
<para>
Most people do not have the technical skills necessary to
cross-compile an entire operating system. Even if they do, they
usually do not want to devote the time and effort required to
bootstrap and compile an operating system just to be able to run
Linux.
</para>
<para>
Fortunately, the early Linux programmers quickly realized the
impracticality of source-code only releases early in Linux's
development and created what they called
distributions���collections of precompiled binaries of the Linux
kernel and other necessary software that users often wanted.
Rather than installing Minix, compiling the Linux kernel and other
required software applications under Minix, and installing those
compiled binaries of the Linux kernel and essential Linux
applications, users could just install these distributions,
immediately having a functional Linux environment in which to
work.
</para>
<para>
Early distributions, such as MCC and SLS, initially represented
little more than archived snapshots of their developer's hard
drive. They offered the user performing the installation little or
no control over what applications were put on the system. Whatever
the distribution developer had on his hard drive was what the
distribution installer got on her hard drive. Even this was much
better than rolling your own distribution by hand. SLS, for
example, stood for Soft Landing System, and was designed to make
the experience of installing Linux easier, hence providing a
���soft landing.��� MCC Interim Linux, from the Manchester
Computing Centre, was the first distribution to sport a combined
boot/root disk, another attempt to make life easier for those
adopting Linux.
</para>
<para>
Distribution developers quickly realized, however, that more
flexibility was needed and began looking for ways to provide
choices both during and after installation. The Slackware
distribution, for example, divided applications into several
functional categories. All users installed the base distribution;
users could then selectively install only the additional
supplemental categories they needed. If networking support was
desired, for example, the networking bundle could be installed.
Similarly, if a graphical user interface was desired, the X bundle
could be installed, making the X Window System available. This
concept offered rudimentary control over what was installed but
only at a very coarse level. Installing the X bundle put several
applications (multiple X terminal emulators, several different
window managers, and so forth) on the system, and all users who
installed the bundle got all of those applications whether they
wanted them all or not.
</para>
<para>
The next logical step in distribution evolution was the
development of more advanced tools to control what was installed.
Several distributions independently developed the notion of
application-level installation management. The developers of these
distributions realized that Slackware and similar distributions
were heading in the right direction, but simply had not made
software management granular enough. Slackware allowed
installation and uninstallation (after a fashion) of bundles of
related applications, but what was really needed was installation
and uninstallation on an application-by-application basis.
</para>
<para>
In late 1993, Rik Faith, Doug Hoffman, and Kevin Martin began
releasing the first public betas of the BOGUS Linux distribution.
BOGUS was notable for the package management system (pms) software
that was used with it for installation and uninstallation of all
software on an application-by-application basis. Shortly
thereafter, in the summer of 1994, the first public betas of Red
Hat Commercial Linux were released. Red Hat initially used Red Hat
Software Program Packages (RPP) as the basis of its Linux
distribution. Like pms, RPP was a system-management tool that
allowed for easy installation and uninstallation of applications.
In late 1993, Ian Murdock founded the Debian Gnu/Linux
distribution. He began seriously developing its dpkg
application-management software by the summer of 1994. Like pms
and RPP, dpkg made it possible to manage each application on the
system.
</para>
</sect1>
<sect1>
<title>RPM Design Goals</title>
<para>
All of these early system-management tools took a similar
approach. They provided the capability to install an entire
application with a single command, to track the files it put on
the system, and to remove those files by using another single
command. As the preponderance of multiple early tools suggests,
this approach to system management was popular. All of these early
tools, however, had numerous technical or practical deficiencies.
Some tools were designed only for Linux on 32-bit Intel-compatible
hardware, even though Linux by this point was already running on
other CPUs in addition to the IA32 family. As Linux was spreading
to multiple architectures, a package-management system that could
produce packages for multiple architectures was needed. Other
tools had technical flaws in how they prepared packages, making it
difficult to verify that packages had been prepared correctly or
to see exactly how the software was prepared.
</para>
<para>
Because of these concerns, after their initial releases of
RPP-based distributions, Red Hat looked closely at both their own
RPP software and other software such as BOGUS's pms software.
Developers at Red Hat, particularly Marc Ewing and Erik Troan, set
out to develop what they initially called the Red Hat Package
Manager (RPM). Based on experiences with earlier Linux packaging
software and knowledge about packaging tools used on other
platforms, Red Hat had several design goals in mind when they
developed RPM. These design points include the following features:
</para>
<para>
*Ease of use
</para>
<para>
*Package-oriented focus
</para>
<para>
*Upgradability of packages
</para>
<para>
*Tracking of package interdependencies
</para>
<para>
*Query capabilities
</para>
<para>
*Verification
</para>
<para>
*Support for multiple architectures
</para>
<para>
*Use of pristine sources
</para>
<para>
The following sections demonstrate how Red Hat incorporated each
of these design goals into RPM.
</para>
<sect2>
<title>Ease of use</title>
<para>
Perhaps the primary design goal for RPM is that it must be easy
to use. Manual software installation has been the primary method
of putting software onto Unix boxes for over 30 years now and
has worked very well for those three decades. To offer a
compelling reason to use the new software, Red Hat's RPM must be
significantly easier to use than other Linux package-management
tools. For that reason, most tasks that can be handled using RPM
were designed to be carried out via a single command. For
example, software installation using RPM requires a single
command (rpm -U software_package), while manual software
installation using older manual methods typically requires at
least six steps to complete the same task:
</para>
<para>
1.tar zxf software_package
</para>
<para>
2.cd software_package
</para>
<para>
3../configure
</para>
<para>
4.make
</para>
<para>
5.su
</para>
<para>
6.make install
</para>
<para>
Similarly, removal of applications installed using RPM requires
a single command (rpm -e software_package); manual removal of an
installed application requires that each file associated with
that application be manually deleted.
</para>
</sect2>
<sect2>
<title>Package-oriented focus</title>
<para>
Like its predecessors, RPM is intended to operate on a package
level. Rather than operating on a single-file basis (as when you
manually install software using Unix command-line tools like mv
and cp) or on an entire system basis (as with many PC operating
systems, which provide the ability to upgrade entire releases
but not to upgrade individual components), RPM provides software
that can manage hundreds or thousands of packages.
</para>
<para>
Each package is a discrete bundle of related files and
associated documentation and configuration information;
typically, each package is a separate application. By focusing
on the package as the managed unit, RPM makes installation and
deletion of applications extremely straightforward.
</para>
</sect2>
<sect2>
<title>Package upgradability</title>
<para>
In addition to its package-oriented focus, RPM is designed to
support upgrading packages. Once an application has been
installed from an RPM package, a newer version of the same
application can be installed using RPM. Doing so upgrades the
existing application, removing its old files and replacing them
with new files. In addition, however, RPM takes care to preserve
any customizations that have been made to that application. The
Apache Web server application, for example, is commonly
installed on Linux machines that need the ability to serve Web
pages.
</para>
<para>
Apache's configuration information, which specifies things such
as which files on the system should be made available as Web
pages and who should be able to access those Web pages, is
stored in a text file, typically /etc/httpd/conf/httpd.conf.
Suppose Apache has been installed using RPM and that you have
then customized httpd.conf to specify its configuration. If you
upgrade Apache using RPM, as part of the upgrade procedure, the
RPM application will take precautions to preserve the
customizations you have made to the Apache configuration. In
contrast, manual upgrades of applications often overwrite any
existing configuration files, losing all site customizations the
system administrator has made.
</para>
</sect2>
<sect2>
<title>Package interdependencies</title>
<para>
Software that manages the applications installed on the system
on an application level (such as RPM) does have one potential
drawback in comparison with system-wide software management
systems (such as PC operating systems like Microsoft's Windows
or IBM's OS/2, which allow the entire system to be upgraded but
do not generally allow individual components to be upgraded,
added, or removed). Software applications often have
interdependencies; some applications work only when other
applications are installed.
</para>
<para>
The Postfix and Sendmail mail transfer agent (MTA) applications
that are commonly used on Linux boxes to serve e-mail, for
example, can both be configured to require users to authenticate
themselves (by submitting a correct user name and password)
successfully before they can use the e-mail server. This feature
is often used to prevent unauthorized access to the e-mail
server, preventing unscrupulous advertisers from using the
server as a tool to send unsolicited commercial e-mail (or UCE,
popularly known as spam). For this optional feature of Postfix
and Sendmail to work, however, additional software must be
installed. Both applications use another application, Cyrus
SASL, which provides the Simple Authentication and Security
Layer (SASL) software that Postfix or Sendmail can use to check
user names and passwords. In other words, Postfix and Sendmail
depend on Cyrus SASL.
</para>
<para>
For system-wide software management systems, logical
interdependencies between system components such as these are
easy to track. All required components are included as part of
the system, and upgrading the system upgrades all these
components, ensuring that all can still interoperate. On
Microsoft Windows 2000, IIS (the application used on Windows to
serve Web pages) requires several other applications such as
EventLog (the Windows application that records system events,
much like the Linux syslogd and klogd software) to be present.
Since Windows is managed on a system level, not a package level,
this dependency is guaranteed to be satisfied. On Linux systems
using RPM, however, the situation is different. On Linux, for
example, the Postfix application requires the syslogd
application, which records system events. However, RPM provides
the flexibility to install some applications but not install
others or to uninstall others later. When you install Postfix,
you have no guarantee that syslogd is already installed. If
syslogd is not installed, Postfix will not work correctly.
</para>
<para>
To avoid problems, Red Hat developers realized that RPMs must
also track dependency information about what software they
require for correct functionality, and that the RPM install and
uninstall applications must use this dependency information.
Because of dependencies, installing Postfix using RPM on a
system without syslogd installed generates a warning that
syslogd must also be installed. Similarly, attempting to
uninstall syslogd from a system that already has Postfix
installed generates a warning that installed applications
require the software that is being deleted. These warnings can
be overridden if necessary, but by default RPM enforces these
dependencies (refusing, for example, to let you uninstall
syslogd without also uninstalling applications that require it,
such as Postfix), preventing you from accidentally breaking
applications by inadvertently uninstalling other software that
they require to operate.
</para>
</sect2>
<sect2>
<title>Query capabilities</title>
<para>
As part of its implementation, the RPM software maintains a
database on the system of all packages that have been installed,
and documenting which files those packages have installed on the
system. RPM is designed to be queried easily, making it possible
for you to search this database to determine what applications
have been installed on the system and to see which packages have
supplied each file on the system. This feature makes RPM-based
systems extremely easy to use, since a single RPM command can be
used to view all installed applications on the system.
</para>
</sect2>
<sect2>
<title>Package verification</title>
<para>
RPM also maintains a variety of information about each installed
file in this system database, such as what permissions each file
should have and what size each file should be. Red Hat
developers designed this database to be useful for software
verification. Over time, installed software will fail to work
for reasons as mundane as the system administrator setting
incorrect permissions on files or as exotic as nuclear decay of
one of the computer's atoms releasing an alpha particle that can
affect the computer's memory, corrupting that bit of memory and
causing errors. Although RPM cannot prevent all errors that
cause installed software to fail (obviously, there's not a
single thing any software can do to prevent nuclear decay), it
can be used to eliminate common errors. When an application
fails, you can use the RPM database to make sure that all files
associated with that application still have correct Unix file
permissions and that no files associated with that application
have become altered or corrupted.
</para>
</sect2>
<sect2>
<title>Multiple architectures</title>
<para>
Most of the RPM design goals mentioned so far are intended
primarily to ease the life of system administrators and others
who regularly install, remove, and upgrade applications or who
need to see what is installed or verify that installed
applications have been installed correctly. Some of the design
goals for RPM are intended primarily not for those sorts of
users of RPM but for users who must prepare software to be
installed using RPM.
</para>
<para>
One of the major limitations of early Linux package management
utilities was that they could produce packages suitable only for
installation on one type of computer: those that used 32-bit
Intel-compatible CPUs. By 1994, Linux was beginning to support
other CPUs in addition to the originally supported Intel CPUs.
(Initially, Digital's Alpha processor and Motorola's 68000
series of processors were among the first additional CPUs that
Linux supported. These days, Linux supports dozens of CPU
architectures.) This posed a problem for distribution developers
such as Red Hat and Debian and for application vendors who
desired to package their software for use on Linux. Because the
available packaging methods could not produce packages for
multiple architectures, packagers making software for multiple
CPUs had to do extra work to prepare their packages.
</para>
<para>
Furthermore, once the packagers had prepared packages, no method
was available to indicate the architecture the packages
targeted, making it difficult for end users to know on which
machine types they could install the packages.
</para>
<para>
Red Hat decided to overcome these limitations by incorporating
architecture support into RPM, adding features so that the basic
setup a packager performs to create a package could be leveraged
to produce packages that would run on various CPUs, and so that
end users could look at a package and immediately identify for
which types of systems it was intended.
</para>
</sect2>
<sect2>
<title>Pristine sources</title>
<para>
The BOGUS distribution's pms packaging system introduced the use
of pristine source code to prepare packages. With Red Hat's
early RPP package system and other similar early efforts,
software packagers would compile software manually, then run
commands to produce a package of that compiled software. Any
changes made to the application's original source code were not
recorded and would have to be recreated by the next person to
package that software. Furthermore, end users wanting to know
what changes had been made to the software they were running had
no method of accessing that information.
</para>
<para>
With RPM, Red Hat developed a package system that produced two
types of packages: binary and source. Binary packages are
compiled software that can be installed and used. Source
packages contain the source code for that software, along with a
file documenting how that source code must be compiled to
produce that binary package. This feature is probably the single
most significant difference between modern Linux packaging
software (such as RPM) and the packaging software used on other
systems (such as the pkg format that commercial Unix systems
use). Source packaging makes the job of software packager
easier, since packagers can use old source packages as a
reference when preparing new versions of those packages. Source
packages are also convenient for the end user, because they make
it easily possible to change options with which that software
was compiled and to produce a new binary package that supports
the features the user needs.
</para>
</sect2>
</sect1>
<sect1>
<title>RPM Terminology</title>
<para>
When working with RPM, understanding the package concept is key.
RPM packages are provided as compressed archive files that contain
one or more files, as well as instructions specifying installation
information about those files, including the ownerships and
permissions that should be applied to each file during
installation. The instructions can also contain scripts to be run
after installation or before uninstallation. These package files
are extremely convenient; they provide a single file that can be
easily transferred between machines for installation rather than
having to transfer each file to be installed.
</para>
<para>
To help in installation and management, all package files are
labeled with highly identifiable names. Red Hat Linux package
files have four-part names, which typically look something like:
</para>
<para>
kernel-smp-2.4.18-3.athlon.rpm
</para>
<para>
kernel-smp-2.4.18-3.i586.rpm
</para>
<para>
kernel-smp-2.4.18-3.i686.rpm
</para>
<para>
kernel-source-2.4.18-3.i386.rpm
</para>
<para>
rootfiles-7.2-1.noarch.rpm
</para>
<para>
Here, the four parts of each name are separated from each other by
dashes or periods. The structure of the package file name is
</para>
<para>
name-version-release.architecture.rpm
</para>
<para>
The name identifies what software is contained within the archive
file. Typically, this is a name of an application or package that
the archive installs on the system. For example, kernel-smp can be
installed to provide a very important application, the SMP
(symmetric multiprocessing, meaning it supports systems with more
than one CPU in them) version of the Linux kernel, on the system.
Sometimes, rather than an application, the software is a
collection of other files needed on the system. The rootfiles
package, for example, is not an application but is a collection of
basic environmental configuration files for the root user's
account (such as /root/.bashrc, the root user's Bash configuration
file) that provides a usable, preconfigured working environment
for the root user on Red Hat Linux systems.
</para>
<para>
The second field in every Red Hat Linux package file's name is the
version field. This field identifies the version number of the
software that is contained in the package file. For example,
kernel-smp-2.4.18 indicates the RPM holds the 2.4.18 release of
the SMP version of the Linux kernel, and rootfiles-7.2 is the 7.2
release of the rootfiles configuration files.
</para>
<para>
Every Red Hat Linux package file name also has a third component:
the release field. This field identifies which release of that
version of the software the package file contains. Package files
contain both software and instructions about how to install that
software. As packages of a particular version of software are
being prepared, mistakes are sometimes made in these instruction
files, or bugs are sometimes fixed within a software version; more
recent package files of that software version need to be prepared
that correct the problem. The ���1 in the rootfiles-7.2-1 package
shows this is the first release of the 7.2 version of the
rootfiles software. The packager of rootfiles version 7.2 got
everything right on the first try and had no need to prepare more
than one release. The ���3 in the kernel-smp-2.4.18-3 package, on
the other hand, is the third release of the 2.4.18 version of the
SMP-capable Linux kernel. This release incorporates new patches to
fix bugs present in older releases of the 2.4.18 version of the
Linux SMP kernel. The software packager increased the release
number so that end users could distinguish the more recent,
bug-fixed package file from the older, less bug-free package file.
</para>
<para>
The final field in Red Hat Linux package file names is the
architecture, which identifies the system types for which the
package file is appropriate. For example, the
kernel-smp-2.4.18-3.athlon package is intended for use on machines
with an AMD Athlon CPU, and kernel-smp-2.4.18-3.i586 is intended
for use on machines with an i586 (Pentium-class) CPU or better. An
architecture name of noarch indicates this is a special
architecture such that the files in the package work on any
architecture. Typically, this is because the files are all
interpreted scripts, not binary executables, or are documentation.
</para>
<para>
RPM supports various architectures. Table 2-1 presents the
architectures available for different platforms as of RPM version
4.1.
</para>
<para>
Table 2-1Supported Architectures
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Platform
</para>
</entry>
<entry>
<para>
Architectures
</para>
</entry>
</row>
<row>
<entry>
<para>
Intel compatible 32-bit
</para>
</entry>
<entry>
<para>
i386, i486, i586, i686, athlon
</para>
</entry>
</row>
<row>
<entry>
<para>
Intel compatible 64-bit
</para>
</entry>
<entry>
<para>
ia64
</para>
</entry>
</row>
<row>
<entry>
<para>
HPAlpha (formerly Digital, Compaq)
</para>
</entry>
<entry>
<para>
alpha, alphaev5, alphaev56, alphapca56, alphaev6,
alphaev67
</para>
</entry>
</row>
<row>
<entry>
<para>
Sparc/Ultra Sparc (Sun)
</para>
</entry>
<entry>
<para>
sparc, sparcv9, sparc64
</para>
</entry>
</row>
<row>
<entry>
<para>
ARM
</para>
</entry>
<entry>
<para>
armv3l, armv4b, armv4l
</para>
</entry>
</row>
<row>
<entry>
<para>
MIPS
</para>
</entry>
<entry>
<para>
mips, mipsel
</para>
</entry>
</row>
<row>
<entry>
<para>
Power PC
</para>
</entry>
<entry>
<para>
ppc, ppciseries, ppcpseries, ppc64
</para>
</entry>
</row>
<row>
<entry>
<para>
Motorola 68000 series
</para>
</entry>
<entry>
<para>
m68k, m68kmint
</para>
</entry>
</row>
<row>
<entry>
<para>
SGI MIPS
</para>
</entry>
<entry>
<para>
Sgi
</para>
</entry>
</row>
<row>
<entry>
<para>
IBM RS6000
</para>
</entry>
<entry>
<para>
rs6000
</para>
</entry>
</row>
<row>
<entry>
<para>
IBM S/390
</para>
</entry>
<entry>
<para>
i370, s390x, s390
</para>
</entry>
</row>
<row>
<entry>
<para>
Platform independent
</para>
</entry>
<entry>
<para>
noarch
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Tip
</para>
<para>
When choosing an appropriate architecture for your machine, be
aware that more recent architectures typically run software that
targets older architectures within the same family; the reverse,
however, is not true. For example, within the 32-bit
Intel-compatible architectures, a 686-class (Pentium II / III /
IV) machine runs files within i386, i486, i586, and i686 RPM
package files, but a 386-class (80386) machine runs files within
i386 RPM package files only. Similarly, for the Alpha
architecture, more recent Alpha EV68 CPUs can run programs from
RPM package files with alphaev67, alphaev6, alphaev56, alphaev5,
and alpha architectures, but an older Alpha EV56 machine can run
programs from RPM package files with alpha, alphaev5, or alphaev56
architectures only.
</para>
<para>
Notice that the four fields in RPM package file names are
separated from each other by punctuation, either a dash (-) or a
period (.). Periods and dashes, however, are also allowed within
fields. 7.2 is a valid version number, just as kernel-source is a
valid software name. Finally, keep in mind that all RPM package
files use an .rpm file-name extension to denote that they are
RPMs.
</para>
<para>
Once installed, package names are slightly different from package
file names. Package files, which can be downloaded from the
Internet, copied off of CDs, and otherwise easily transferred
between machines, always have names that looks like
name-version-release.architecture.rpm. Installed packages,
however, have names that look like name-version-release. Once
installed, packages are referred to without the architecture field
and the .rpm extension. Furthermore, installed packages consist of
lots of files, not a single RPM file. For example, the package
file kernel-smp-2.4.18-3.i686.rpm after installation is referred
to as kernel-smp-2.4.18-3. To simplify usage even further,
installed packages can be referred to by their name field only, so
this file would become simply kernel-smp.
</para>
<para>
Warning
</para>
<para>
Once installed, the name of the package does not have to be the
same as the name portion of the original package file. By
convention though, the package name matches the name, version, and
release part of the file name.
</para>
<para>
Usage of the name field by itself to name packages assumes that
multiple versions or releases of that particular software are not
installed. However, it is in some cases necessary to install
different versions or releases of the same package. My desktop at
home is a (by now, relatively old) dual Pentium-II system, so it
uses an SMP-capable Linux kernel. On it, I have the following
Linux SMP kernels installed:
</para>
<para>
$ rpm -q kernel-smp
</para>
<para>
kernel-smp-2.4.18-4
</para>
<para>
kernel-smp-2.4.18-3
</para>
<para>
kernel-smp-2.5.21-4
</para>
<para>
$
</para>
<para>
This example uses the rpm ���q command to query for all installed
versions of the given package, kernel-smp.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 5 covers querying the RPM database in depth.
</para>
<para>
I have two different package file releases (release 3 and release
4) of the 2.4.18 version of the Linux kernel, and I have a
development kernel, version 2.5.21, installed. On this system,
since I have multiple packages installed of the kernel-smp
software, I have to use the full package name (such as
kernel-smp-2.4.18-4) whenever I want to work with my installed
kernel-smp packages.
</para>
</sect1>
<sect1>
<title>Summary</title>
<para>
The RPM system wasn���t created to solve some theoretical problem.
Instead, it is the result of years of hard-won practical
experience in trying to manage systems with a large number of
applications. RPM builds upon older systems that were created to
solve some of the problems faced by system administrators. RPM
goes further, though, and tries to provide a complete
package-management solution. This includes the ability to deal
with wrinkles that Linux faces but that many other operating
systems do not need to address.
</para>
<para>
For example, most other operating systems don���t support more
than one or two processor architectures. Sun���s Solaris, for
example, supports only the SPARC and Intel architectures. Linux
supports these and more. Most other operating systems also don���t
include nearly so many applications. From the OpenOffice.org
office suite to the Apache Web server, Linux distributions are
literally packed with applications. As a final point, most other
operating systems provide mostly closed-source applications.
Linux, on the other hand, includes thousands of open-source
applications.
</para>
<para>
From the perspective of the organizations making Linux
distributions, these wrinkles make Linux harder to manage. Luckily
for end users, the solution to these problems helps make the RPM
system better able to manage user systems:
</para>
<para>
*The RPM system tags each package with the processor architecture
and allows for multiple versions of the same package to be
installed on the same system. RPM also packs all the files in a
package into one file, called an RPM file, for easy transfer to
other systems.
</para>
<para>
*Most RPM operations such as installing or removing packages
require only a single command to run.
</para>
<para>
*The RPM system supports building RPM packages from a pristine set
of sources. This means you can reproduce the commands required to
build an application, improving quality.
</para>
<para>
This chapter introduced the RPM system and the history behind it.
The next chapter delves into the RPM basics, including files,
database, and commands.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-intro-packaging-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv593
Added Files:
rpm-guide-intro-packaging-en.xml
Log Message:
--- NEW FILE rpm-guide-intro-packaging-en.xml ---
<!-- $Id: -->
<preface id="ch-intro-packaging">
<title>Introducing Package Management</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para>
In This Chapter
</para>
<para>
*Issues in software management
</para>
<para>
*Examining Linux management tools
</para>
<para>
*Introducing the package concept
</para>
<para>
In 1991, a young Finnish graduate student started a new personal
hobby. He had acquired an Intel 386 computer and had spent a few
weeks exploring it and playing early PC computer games. Eventually,
however, he grew bored with the limitations of the MS-DOS
environment that had come with his toy and decided that he wanted an
operating system for it that he could use more productively. After
exploring Minix, a feature-limited teaching operating system, he
decided he needed a full-featured OS.
</para>
<para>
At that time, no full-featured PC operating systems were freely
available, so he decided to write his own operating system. Today,
that small hobby OS that Linus Torvalds started almost as a whim has
become Linux (www.linux.com), a significant new variant of Unix that
runs millions of the world's network servers and, increasingly,
desktop computers and embedded processors.
</para>
<para>
Linux has grown up, successfully making the transition from a
one-man personal project to a functional, full-featured operating
system used by many of the world's major corporations and deployed
on millions of corporate and personal systems. Along the way, Linux
has had to address many of the same issues any new operating system
must face. One of these concerns is how software for Linux, and how
the Linux operating system itself, should be installed. How can
administrators safely remove software packages without affecting
other installed packages? And how can you safely upgrade packages?
Answering these questions is what this book is all about.
</para>
<sect1>
<title>Installing, Removing, and Upgrading Applications</title>
<para>
Applications for most operating systems consist of multiple files
that must be copied to specific locations on the computer's file
system before each application can be run. This is true for common
PC operating systems such as MS-DOS or Microsoft Windows, as well
as for Unix and Linux.
</para>
<para>
In the case of a Unix-like operating system such as Linux, other
issues must also be considered. Unix and Linux are multiple-user
systems, so they must track ownership of files. Furthermore, Unix
and Linux use a system of file permissions. Administrators can
grant some users access to files and can control how users may
access those files, for example, allowing some users the
permission to read only certain files. Administrators can deny
other users access to the same files. So, installation of an
application on Linux requires consideration of all these details.
After files are copied into their appropriate locations, they must
be granted correct permissions and correct ownerships.
</para>
<para>
Similarly, administrators occasionally need to remove installed
software from the computer. Maybe the program is no longer needed;
maybe it does not work correctly for the needed task, or maybe the
space it is using is needed for more important programs. In
addition, installed software sometimes needs to be upgraded.
Perhaps a new version of the software has come out and the
currently installed version needs to be replaced with the
presumably improved version. In most respects, software upgrades
are the same as the removal of one application (the old version),
followed by installation of another application (the new version).
Upgrades do, however, have additional issues. Many applications
must be configured before they can be used. Ideally, the upgrade
for an installed application takes the current configuration into
account, preserving old configuration information and applying it
to the recently installed version.
</para>
<para>
All these considerations make installation of a new application
onto Unix or Linux a labor-intensive process. To further
complicate matters, Unix applications have primarily been
distributed as source code. To install a new application, such as
the Apache Web server, you download the source code for that
application���in this case, from the Apache Project's Web page
(http://httpd.apache.org). Typically, the source code is provided
in some sort of archive (such as the Zip archival and compression
format often used in the Windows world or the tar archive format
typically used in the Unix world) that you must then unpack. After
unpacking this source code, you have to configure it to support
the options and systems you want, compiling it to produce an
executable program that can run on your particular operating
system (CPU combination).
</para>
<para>
After compiling the source code, you still have to install the
application by putting all of its components (executable programs,
documentation, configuration files, and so forth) into the correct
locations on your hard drive and setting correct permissions on
all those files. You might also need to perform other steps to
prepare the system for the software. In the case of Apache, for
example, some space needs to be set aside for storage of
Web-access logs, and a special user account needs to be created so
that the Apache Web server can operate more securely. Finally, you
are ready to try running the application you have spent so much
time installing.
</para>
<para>
To help with all these tasks, precompiled software is becoming
increasingly prevalent in the Unix and Linux communities, so you
might be able to find executable (precompiled binary) copies of
the application you wish to install that are appropriate for your
particular machine's CPU. In that case, download an archive of the
compiled application and unpack it. Then skip the compilation
step, since that has already been done for you. The other steps
required to install the package (copying files into correct
locations, setting file permissions, and doing any needed system
or application configuration) are exactly the same as the steps
performed to install that application from source code. Once those
steps are finished, you are ready to test your freshly installed
application.
</para>
<para>
When you run your newly installed application, you might be
thrilled, perhaps discovering that it is something you want to use
regularly. On the other hand, you might discover that you have no
use for the software you have just installed, deciding that you
want to uninstall it.
</para>
<para>
Uninstallation occurs by reversing the installation steps.
Remember any special steps you have performed (such as adding a
user account), and undo those. Then remember all the files you
have installed and where you have installed them. Manually delete
them. As you can see, this can become a pretty tedious exercise.
</para>
<para>
If you like the application you have installed, you will likely
find yourself wanting to upgrade it eventually. The Apache Web
server, for example, like any network service, must be upgraded
whenever security problems are found and fixed. If you find that
you need to upgrade Apache, you need to back up your Apache
configuration files and then uninstall Apache. The next step is to
install a new version of Apache, applying your
Apache-configuration customizations to your new installation of
Apache.
</para>
<para>
All of this is a big pain. There has to be a better way. And there
is.
</para>
</sect1>
<sect1>
<title>Overcoming the Installation Obstacles</title>
<para>
None of the tasks you must perform to install, upgrade, or
uninstall applications are especially difficult. However, these
steps quickly become daunting when you consider all the files that
must be managed. A full Red Hat Linux 7.3 installation provides
around 3,000 executable commands and over 160,000 total files
(some other Linux distributions are even larger!). Obviously,
managing all these files by hand, although theoretically possible,
is not technically feasible. On a smaller scale, even management
of single applications is not practical. The Postfix e-mail server
application, for example, consists of around 275 files scattered
in a dozen or so different directories. Imagine trying to remember
and manually remove all of those files (and only those files) to
uninstall Postfix from your system!
</para>
<para>
All the steps needed to manage software on Unix or Linux systems
are hardly unique to Unix; all operating systems have similar
procedures that must be followed to make software usable on the
system. For this reason, many approaches have been adopted toward
software installation, uninstallation, and upgrading.
</para>
<sect2>
<title>Application-level utilities</title>
<para>
Some operating systems, such as MS-DOS, have supplied absolutely
no built-in tools for software management. Installation of
applications on such systems occurs in one of two ways: software
is installed manually, using file-copy utilities to put all the
application files in the appropriate places on the system, or
software is installed using a custom-written installation
application (as is usually the case for MS-DOS applications).
</para>
<para>
Once installed, software can be uninstalled in one of two ways:
you can manually delete each file installed for the application
(assuming you can even remember them all), or the application
might come with a custom uninstallation utility that can be run
to remove the application. Upgrading an already installed
application on such a system uses a similar procedure. If the
application comes with an installation utility capable of
handling application upgrades, you can use the utility to
perform the upgrade. Otherwise, the software must be manually
upgraded using the procedure described previously.
</para>
<para>
Note
</para>
<para>
Current versions of Windows, such as Windows XP, though, have a
central database of installed applications.
</para>
</sect2>
<sect2>
<title>Built-in system utilities</title>
<para>
Other operating systems have come with built-in utilities that a
system administrator can use to manage the system���s software.
These utilities can be run to install the software on the
system; typically, they take some of the work out of manually
installing software, dealing with issues such as figuring out
which files need to be put where on the system. Once installed,
these utilities typically track the files that have been
installed. This knowledge can usually be used to uninstall those
applications automatically. Since the software knows which files
are associated with the application, it can be told to uninstall
the application, and it can find and delete all the files that
belong to that application.
</para>
<para>
These built-in utilities typically come in two different forms.
One type focuses on managing the installation process, providing
custom utilities that can be used to perform the otherwise
manual tasks of compiling software and copying files into their
final locations. The three major freely available Berkeley Unix,
or BSD, operating systems, NetBSD, FreeBSD, and OpenBSD, for
example, ship with a software-management system called,
variously, ports (FreeBSD and OpenBSD) or packages (NetBSD).
</para>
<para>
The ports system is composed of extensions to the normal Unix
software-compilation utilities that help it automate and track
many of the steps of a standard source-code compilation. When
using ports, you still download source code, unarchive it,
configure it, compile it, and install it, but the ports software
automates many of these steps. Furthermore, the ports system
does limited tracking of the files it installs. Although it does
not offer more advanced features (such as an interface to search
all installed files to see what application supplied that file)
or the ability to upgrade installed applications, it does
provide the ability to uninstall applications that are installed
using ports. These sorts of limitations are typical of
management applications that function as the ports system does,
by enhancing the compilation and installation phases of
application installation. The packages system on NetBSD has
similar limitations.
</para>
<para>
Other system-management utilities focus less attention on
compiling an application for installation and more attention on
the files that must be installed on the system after the
application has been compiled.
</para>
<para>
For example, the standard System V Unix package-management
software supplied with most commercial Unix systems (Sun's
Solaris, for example) devotes no attention to management of
software compilation at all. Instead, it tracks the individual
files associated with each application in a system database.
</para>
<para>
To install software using the System V tools, you must compile
the software. After compiling the software in the standard
fashion, prepare a list of the files from that compilation that
need to be installed on the system. Be certain to state where
the files need to be installed and what permissions and
ownerships they need to have once installed. Then run a series
of commands that look at this list, find the files listed in it,
and archive them into one file, along with a copy of this list
that specifies where they should be installed and the ownerships
and permissions. This single archive file can then be
transferred to other machines, where a System V
software-management command can be used to install it. This
System V installation command (typically called pkgadd) unpacks
the archive, copies the files into their final destinations
based on the enclosed listing, and sets permissions and
ownerships on the files as specified by the listing. Finally,
this pkgadd command registers the list of freshly installed
files into a system-wide database of installed files.
</para>
<para>
Such a system offers several advantages over manual software
installation. Software can now be installed and uninstalled
easily, and the system-wide database of installed files can be
readily searched to locate installed applications and files.
However, this sort of system also has severe limitations; it is
far less flexible in the software-configuration stages than
software such as the FreeBSD ports system, which offers great
control over the software-compilation stage of software
installation.
</para>
</sect2>
</sect1>
<sect1>
<title>Linux Software Management Tools: Packages</title>
<para>
Initially, Linux had neither type of software-management tool. In
the early days of Linux, you installed Linux by cross-compiling it
under a different operating system (Minix), then manually
installing the compiled Linux programs into the appropriate
locations to produce a working system. As Linux has matured,
however, it has acquired software-management tools that have made
software installation, removal, and upgrade significantly easier
than in the early days. The exact software-management tool used on
modern Linux systems varies from distribution to distribution, but
both approaches to system management can be found in the tools
used by various distributions.
</para>
<para>
The Gentoo Linux (www.gentoo.org) distribution, for example, uses
a software-management system called Portage, which is very similar
to the FreeBSD ports system. Like ports, Portage provides great
control over software compilation and installation, providing a
collection of scripts that automate much of the basic work of
downloading and compiling software.
</para>
<para>
At the other end of the spectrum, the now-defunct deepLinux
distribution used a software-management system called deep-package
(still available from
www2.cddc.vt.edu/linux/distributions/deeplinux/tools. deep-package
was intended to be a complete reimplementation of the Solaris
pkgadd utility and its helpers. Like the Solaris pkgadd software,
deep-package paid no attention to half of the question of how to
manage software, focusing entirely on software installation and
tracking issues while entirely ignoring the initial compilation of
the software.
</para>
<para>
More typically, however, Linux software-management tools use an
approach somewhere between the two extremes represented by Portage
and deep-package. Most Linux software-management tools provide
software that manages the compilation of software, similarly to
the FreeBSD ports tools. However, these software-management tools
typically produce packages from the software they compile. Much
like the archives produced by the System V software-management
tools, packages are simply archive files that contain two things:
a collection of related files, which together have a common use,
and a script that provides all the metadata about those files
necessary to install and manage those files.
</para>
<para>
Typically, packages represent applications. For example, a Postfix
package contains the 275 files that make up Postfix and a script
that specifies where on the system those 275 files need to be
placed, as well as what permissions and ownership those files
need. A single command can then take this Postfix package file,
extract its 275 archived files, and use the script to place those
files correctly on the system.
</para>
<para>
In addition, most Linux software-management tools have a database
component that tracks files and applications that have been
installed using the package-management software, helping the
package manager do its job of easing the management of installed
software.
</para>
<para>
In the case of my full Red Hat Linux 7.3 installation, this
package-management software maintains a database of information
regarding all 160,000 files on the system; as applications are
installed on the system, this database is updated with information
regarding the new application and the locations of its component
files. This database is the key component, making it possible to
manage the system. Since this database remembers which 275 files
compose the Postfix application, it ensures that I can uninstall
Postfix with a single command that accesses this database, without
my having to remember the locations of all 275 files that make up
the Postfix application.
</para>
<para>
A wide variety of software-management tools are available for
Linux to help lessen the work involved with installing, removing,
and upgrading applications installed on the system. This book
focuses on one of these tools, the RPM Package Management
software, or RPM.
</para>
<para>
Note
</para>
<para>
RPM was originally called Red Hat Package Manager. After adoption
by other Linux distributions, the name has changed to simply the
RPM Package Manager. The RPM initials remain the same.
</para>
<para>
As the original name implies, RPM was developed by Red Hat, Inc.,
the major Linux distributor in the United States. Even though the
original name seems to point to a Red Hat-only solution, most
Linux distributions use the RPM software. The RPM software
provides a foundation needed by Linux system administrators
throughout the world. You can even use RPM on other operating
systems, both Linux and non-Linux, as covered in Chapters 19 and
20, respectively.
</para>
<para>
The RPM system provides all of the features needed to manage
applications, including a database of installed packages with
their version numbers, the ability to install, remove, and update
packages, and the ability to recompile an application from a
source code RPM package.
</para>
<para>
The remaining chapters in Part I go into depth on what you can do
with RPM packages and the commands you need to work with the RPM
system:
</para>
<para>
*Chapter 2 provides an overview of the RPM system, exploring what
it was designed for and where it has weaknesses.
</para>
<para>
*Chapter 3 discusses the technical details of how the RPM system
works, where the database of packages gets stored, and what
commands should be available for working with RPM packages.
</para>
<para>
*Chapter 4 continues the discussion by covering the three major
tasks you need to perform with RPM packages: installing software,
removing software, and upgrading software you have already
installed.
</para>
<para>
*Chapter 5 covers the RPM database, how it works, where it
resides, and how you can use it to better manage your system.
</para>
<para>
*Chapter 6 delves into package dependencies, a very important
concept. Most major applications depend on a number of other
packages. Sometimes these dependencies get very complex, with one
package depending on particular versions of other packages. With
thousands of packages on your system, this can lead to a big mess.
Chapter 6 helps you sort through the issues.
</para>
<para>
*Chapter 7 covers the important issue of transactions, so that you
can ensure your system gets updated in an orderly manner and so
that you can roll back changes if something does not work out.
</para>
<para>
*Chapter 8 introduces a host of tools that can help you find RPM
packages as well as manage the packages on your system. This
includes graphical interfaces on top of the RPM system and special
Internet search sites devoted just to RPM packages.
</para>
<para>
Later chapters cover creating RPM packages, programming with RPM,
and extending the functionality provided by the base RPM system.
</para>
</sect1>
<sect1>
<title>Summary</title>
<para>
Modern operating systems have large complex sets of applications,
resulting in thousands of files to keep track of for upgrades,
installation, and removal of packages. All this complexity has
lead Linux vendors to develop a variety of package-management
tools.
</para>
<para>
This chapter briefly introduced the RPM Package Manager, or RPM
for short. The next chapter provides an overview of the RPM
system, showing how all the parts fit together.
</para>
</sect1>
</preface>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "preface")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-extra-packaging-tools-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv559
Added Files:
rpm-guide-extra-packaging-tools-en.xml
Log Message:
--- NEW FILE rpm-guide-extra-packaging-tools-en.xml ---
<!-- $Id: -->
<chapter id="ch-extra-packaging-tools">
<title>Supplemental Packaging Software</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Understanding packaging aids
</para>
<para>
*Manipulating packages
</para>
<para>
RPM is intended to make system management easier, both for system
administrators and other users who do all the day-to-day work of
installing and removing applications and for developers and other
users who do all the work of preparing applications for
installation. For RPM packagers, the work involved in preparing an
application for installation has two phases: first, the software
must be compiled (if it is not written in an interpreted language
such as Perl) and otherwise configured for the system on which it
will be installed; then the RPM package of the software must be
prepared by creating a spec file that properly packages it into an
RPM. In contrast, packagers who choose to package applications in a
simpler format, such as gzipped tarballs (compressed tar archives),
have less work ahead of them, since they need only concern
themselves with the first step.
</para>
<para>
After a packager has prepared an RPM package once, RPM makes the
first step (compilation and configuration) easier when the packager
has to package an updated version of the same software; RPM does a
lot of work to track compilation commands, any needed patches, and
any configuration modifications discovered to be necessary to
prepare the software. Similarly, once an RPM spec file has been
produced for an application, updating that spec file to support a
newer version of that application is usually trivial. For these
reasons, using RPM instead of a simpler, less end-user-friendly
package format (such as gzipped tarballs) is a bit of a tradeoff for
the packager; preparing an RPM of an application requires a little
more initial time and work than preparing a gzipped tarball of that
same application, but once created, the RPM package takes less time
and effort to keep current than the gzipped tarball requires.
</para>
<sect1>
<title>Packaging Aids</title>
<para>
However, several helper tools are also available for RPM
packagers. These tools can be used at various stages in the
process of producing a high-quality RPM package to simplify the
tasks that an RPM packager must perform. These tools include
syntax-highlighting modes for various text editors, making
production and maintenance of spec files easier; macro packages
for popular text editors, simplifying the generation and
maintenance of spec files; tools that generate spec files,
simplifying initial spec file creation; and debuggers that
validate produced binary RPMs, helping ensure that the spec file
used to create the packages is accurate and high quality.
</para>
<sect2>
<title>Using VIM spec plugins to improve spec file editing</title>
<para>
Unix systems have traditionally shipped the legendary (or
notorious, depending upon your point of view) vi editor
(pronounced vee eye) as their default text editor. Vi was
initially developed by Bill Joy in 1976 for BSD Unix. It
eventually was incorporated in AT& T System V Unix as well
and later was mandated by the POSIX 1003 standards (which define
what an OS must have to be Unix-compatible), thereby conquering
all facets of the Unix world.
</para>
<para>
The original vi source code is no longer freely available, but
several clones of the vi program have been created over the
years. The most popular of these vi clones is probably Vi
IMproved, or VIM (www.vim.org). VIM is the standard vi
implementation (meaning that when you type vi at the command
prompt, the program you really are running is vim) on many Linux
distributions, including Red Hat Linux. It is also freely
available for most other Unixes and even for non-Unix systems
such as Microsoft Windows.
</para>
<para>
VIM is a fully backwards-compatible implementation of the
original vi editor, although it also offers many additional
features that vi did not support. One VIM feature that can be
extremely useful when preparing spec files is colorized syntax
highlighting. VIM has an extensible interface through which it
can be told about the syntax used for files of various types.
Once it understands a filetype's syntax, it can color the
various syntactic structures of that file in different ways. For
example, when editing a Bourne shell script using VIM, comments
are typically blue, control statements (if, for, do, and so on)
are yellow, variables are purple, and so forth. Many people find
this feature very useful, since a single glance reveals the
entire logical structure of the file. Furthermore, errors in the
file (such as a missing done statement failing to close a do
loop in a Bourne shell script) are often immediately obvious
when using such a colorizing editor.
</para>
<para>
Usually, VIM does not understand the structure of RPM spec
files. When preparing a spec file, VIM displays all text in the
same color. A spec.vim syntax file is available for VIM that
makes VIM aware of the syntax used for RPM spec files. When this
file is used, the various structural components (%define,
preamble statements, %build, and so forth) are all colorized,
making the logic of the spec file readily apparent.
</para>
<para>
The spec.vim file that provides VIM with an understanding of
spec-file syntax is bundled with newer versions of VIM, or it
can be downloaded from the Internet. Most RPM-based Linux
distributions, including Red Hat Linux, ship this file with VIM
as part of their distribution and even automatically configure
VIM to load this syntax file any time an RPM spec file is being
edited. When using VIM on a system that does not automatically
load spec.vim whenever spec files are edited, you should
download the spec.vim file (I tend to save such personal
extensions in ~/etc/vim, but you can save it any place you
prefer).
</para>
<para>
Cross Reference
</para>
<para>
Download the spec.vim syntax file for VIM from
http://pegasus.rutgers.edu/~elflord/vim/syntax/spec.vim.
</para>
<para>
Once downloaded, configure VIM to load your new syntax file. You
can do this by putting the following in your ~/.vimrc file
(assuming you have saved the file as ~/etc/vim/spec.vim; adjust
the path as necessary if you saved it elsewhere):
</para>
<para>
augroup syntax
</para>
<para>
au! BufNewFile,BufReadPost *.spec so ~/etc/vim/spec.vim
</para>
<para>
au BufNewFile,BufReadPost *.spec so ~/etc/vim/spec.vim
</para>
<para>
augroup END
</para>
<para>
This statement will instruct VIM to load the syntax file
whenever a file named with a .spec extension is edited. You can
now even customize the colors which VIM uses, if you like, by
editing ~/etc/vim/spec.vim!
</para>
<para>
The VIM editor has hundreds of built-in commands for formatting
text. If necessary, it can even be extended with new commands.
Furthermore, these commands can be defined in FileType plugins,
so that different commands are loaded depending upon the type of
file being edited (just as different syntax matching can be used
depending upon the type of file being edited). Gustavo Niemeyer
has written a spec plugin, pi_spec, which defines various
commands that can be used when working with RPM spec files.
Currently, this plugin can be used to automate maintenance of
the %changelog section of RPM spec files.
</para>
<para>
By default, the spec plugin provides a macro, spec_chglog, which
is mapped to the <LocalLeader>-c key. Normally, the
LocalLeader key in VIM is mapped to "\", a backslash character.
This means you press \c to load the spec_chglog macro. If
desired, you can instead map spec_chglog to a different key by
putting a statement like the following in your ~/.vimrc file.
</para>
<para>
au FileType spec map <buffer> C <Plug>SpecChangelog
</para>
<para>
In this case, that statement would map the macro to the "C" key,
but you can map it to a different key by replacing the "C" in
the statement with whichever key or key combination you prefer.
</para>
<para>
The spec_chglog macro checks the %changelog in the spec file
currently being edited and makes sure that the last entry in
this %changelog was written today and was written by you. If it
was, the macro adds a new item to the entry. If it was not
written today, or was written today, but not by you, the macro
adds an entirely new entry. Optionally, the macro also checks
that the name, version, and release of the package are correct
and will update the release if it is incorrect. In addition, the
macro maps the percent key, %, making it usable in command mode
in VIM to move quickly between sections within a spec file.
</para>
<para>
To help spec_chglog, you can define a few variables in your
~/.vimrc file to customize its behavior. The variable
spec_chglog_format defines what the macro uses for new
%changelog entries. If you do not define this variable, the
macro will ask you for an e-mail address and construct it for
you the first time you use the macro. Alternatively, you can
customize it yourself by adding an entry like the following to
your ~/.vimrc file.
</para>
<para>
let spec_chglog_format = "%a %b %d %Y Your Name
<your(a)email.address>"
</para>
<para>
The preceding format is what Red Hat's developers use for Red
Hat Linux spec files and results in a %changelog entry that
looks like the following, with the user name and e-mail address
changed to protect the innocent:
</para>
<para>
* Mon Apr 15 2002 Bob Marley <bob(a)marley.yow>
</para>
<para>
The variables in the spec_chglog_format control the time format
that is used. If you want different time formats in your
%changelog entry, you can replace the variables (using %A
instead of %a would cause the full weekday name, such as
"Monday", to be printed) using the documentation in the
strftime(3) man page as a guideline.
</para>
<para>
By default, the macro will insert new entry items after existing
items. For example, if I already have a %changelog entry for
today that reads as follows:
</para>
<para>
* Mon May 6 2002 Bob Marley <bob(a)marley.yow>
</para>
<para>
- Updated to newest release
</para>
<para>
Then, using the macro to add a new entry for an additional patch
I added will, by default, result in an entry that reads:
</para>
<para>
* Mon May 6 2002 Bob Marley <bob(a)marley.yow>
</para>
<para>
- Updated to newest release
</para>
<para>
- Added Solaris compile patch
</para>
<para>
If I want, I can instead have new items inserted before existing
items, so that my second entry instead looks like
</para>
<para>
* Mon May 6 2002 Bob Marley <bob(a)marley.yow>
</para>
<para>
- Added Solaris compile patch
</para>
<para>
- Updated to newest release
</para>
<para>
To have new items inserted before existing items, simply add the
following line to your ~/.vimrc file:
</para>
<para>
let spec_chglog_prepend = 1
</para>
<para>
Optionally, the macro can track version and release numbers in
the %changelog entries automatically. Adding the line
</para>
<para>
let spec_chglog_release_info = 1
</para>
<para>
results in the first item in every changelog entry automatically
reflecting the version and release, so that my %changelog entry
might instead look like the following:
</para>
<para>
* Mon May 6 2002 Bob Marley <bob(a)marley.yow>
</para>
<para>
+ httpd-2.0.36-2
</para>
<para>
- Updated to newest release
</para>
<para>
- Added Solaris compile patch
</para>
<para>
If this feature is enabled, the macro automatically checks the
version and release information to make sure that they have
increased. If they haven't, it will offer to update them for
you. Add the following line to your ~/.vimrc file to disable
this feature, if necessary.
</para>
<para>
let spec_chglog_never_increase_release = 1
</para>
<para>
This spec plugin ships with newer versions of VIM. Both it and
the VIM spec syntax highlighting extensions can be very useful
for speeding spec file editing and debugging, and are well worth
trying out if you are a VIM user.
</para>
<para>
Cross Reference
</para>
<para>
You can find out more about vim at www.vim.org.
</para>
</sect2>
<sect2>
<title>Adding functions with emacs rpm-spec-mode</title>
<para>
Of course, not everyone in the world uses VIM. Another commonly
used editor is the emacs editor originally developed by Richard
M. Stallman. Unlike vi, emacs is not considered an essential
Unix component and is not always found installed on a Unix
system, although it is bundled with just about every Linux
distribution.
</para>
<para>
Over the years, two major emacs variants have emerged. GNU Emacs
is produced by the Free Software Foundation and can be
downloaded from www.gnu.org/software/emacs/emacs.html. XEmacs is
based on GNU Emacs and is available from www.xemacs.org.
Historically, the two differed in their user interfaces (XEmacs,
as the name suggests, had an X Window interface, though GNU
Emacs has one as well these days) and in some technical details
of how they operated. Both are freely available under the terms
of the GNU GPL, so you can download and try either or both if
they are not already on your system.
</para>
<para>
Cross Reference
</para>
<para>
See Appendix G for more on the GNU GPL, or General Public
License.
</para>
<para>
Red Hat Linux includes RPMs of both GNU Emacs and XEmacs as part
of the distribution, and most other Linux distributions will
include one or both as well.
</para>
<para>
Like VIM, both GNU Emacs and XEmacs support syntax highlighting.
They are also both extensible, having the ability to load mode
files that add new commands and functions. Stig Bj��rlykke has
written a mode, rpm-spec-mode.el, which works with both GNU
Emacs and with XEmacs to add many functions, making it easier to
use when editing RPM spec files. Red Hat Linux includes and
enables this mode in both GNU Emacs and XEmacs, as do many other
Linux distributions.
</para>
<para>
Cross Reference
</para>
<para>
You can download this emacs mode from
http://tihlde.org/~stigb/rpm-spec-mode.el.
</para>
<para>
After downloading, you will need to put the following lines in
your ~/.emacs init files (for GNU Emacs) or ~/.xemacs init files
(for XEmacs) to instruct emacs to load rpm-spec-mode whenever a
file with a .spec extension is being edited:
</para>
<para>
(autoload 'rpm-spec-mode "rpm-spec-mode.el" "RPM spec mode." t)
</para>
<para>
(setq auto-mode-alist (append '(("\\.spec" . rpm-spec-mode))
auto-mode-alist))
</para>
<para/>
<para>
Once installed, rpm-spec-mode will provide emacs with additional
support for editing RPM spec files. Figure 13-1 shows this mode
in GNU Emacs.
</para>
<para>
54965-0 Fg1301.tiff here; needs to be cropped to just the
central window
</para>
<para>
Figure 13-1: Gnu Emacs using rpm-spec-mode
</para>
<para>
Figure 13-2 shows this mode in XEmacs.
</para>
<para>
54965-0 Fg1302.tiff here; needs to be cropped to just the
central window
</para>
<para>
Figure 13-2: XEmacs using rpm-spec-mode
</para>
<para>
With this mode, emacs can do syntax highlighting of spec files,
just like VIM. The mode file rpm-spec-mode.el contains the emacs
instructions that specify what should be highlighted and what
colors should be used for highlighting.
</para>
<para>
Tip
</para>
<para>
If you do not see syntax highlighting when you edit a spec file,
your emacs session may or may not be currently configured to do
syntax highlighting. First, make sure that the status bar at the
bottom of your emacs window says (RPM-SPEC), indicating that
rpm-spec-mode is being used. If it doesn't, double-check the
rpm-spec-mode installation instructions. If the status bar does
indicate that you are using rpm-spec-mode, also double-check
that syntax highlighting (which, in emacs, is a global
configuration option) has been enabled. In both GNU Emacs and
XEmacs, the Options menu has a Syntax Highlighting option that
must be enabled before emacs will colorize spec file syntactic
structures.
</para>
<para>
In addition to providing syntax colorization, rpm-spec-mode adds
a variety of new functions to emacs that can be used to speed
the process of creating or editing RPM spec files. These new
functions appear on the RPM-Spec menu that is added to emacs by
rpm-spec-mode. Many of the functions are similar to the
functions added to VIM by the spec_chglog macro. Navigation
functions to move quickly through a spec file are provided, so
that Ctrl+C, Ctrl+N (press Ctrl+C followed by Ctrl+N) will move
the cursor to the next major section of the spec file, while
Ctrl+C, Ctrl+P will move the cursor to the prior major section
of the spec file. Similarly, macros are also defined to
increment the release tag (Ctrl+C, R) and the very handy option
to add new %changelog entries (Ctrl+C, E). Like the VIM macros
for adding %changelog entries, the rpm-spec-mode command checks
to see if an entry already exists for today. If not, it adds a
new entry, but if so, it just adds a new item to the existing
entry. For %changelog entries to have the correct e-mail
address, the emacs variable user-mail-address must be set
correctly. If it is not set on your system, you can add the
following line to your emacs initialization files:
</para>
<para>
(setq user-mail-address "your(a)email.address")
</para>
<para>
In addition to these basic functions, rpm-spec-mode offers more
advanced spec file creation support. Opening a new buffer in
emacs for a spec file that does not already exist automatically
generates a skeleton spec file.
</para>
<para>
To further speed things up, emacs offers a number of macros for
the main tasks in writing an RPM spec file. Table 13-1 lists
these macros.
</para>
<para>
Table 13-1Macro commands for The RPM SPEC MODE IN EMacs
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Command
</para>
</entry>
<entry>
<para>
Function
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Tab
</para>
</entry>
<entry>
<para>
Adds a new tag to the spec file
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+F F
</para>
</entry>
<entry>
<para>
Adds a new file to the %files section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+F C
</para>
</entry>
<entry>
<para>
Adds a new configuration file to the %files section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+F D
</para>
</entry>
<entry>
<para>
Adds a new documentation file to the %files section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+F G
</para>
</entry>
<entry>
<para>
Adds a new ghost file to the %files section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+D D
</para>
</entry>
<entry>
<para>
Adds a new directory to the %files section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+D O
</para>
</entry>
<entry>
<para>
Adds a new documentation directory to the %files
section
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+C U
</para>
</entry>
<entry>
<para>
Changes the umask in %defattr entries in %files
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+C O
</para>
</entry>
<entry>
<para>
Changes the owner in %defattr entries in %files
</para>
</entry>
</row>
<row>
<entry>
<para>
Ctrl+C Ctrl+C G
</para>
</entry>
<entry>
<para>
Changes the group in %defattr entries in %files
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Furthermore, rpm-spec-mode even adds macros to emacs that can be
used to build RPMs from spec files without even having to exit
emacs! Since the process of constructing spec files is often
iterative (make new spec, build RPM from spec, find mistake,
edit spec, build RPM from spec, find mistake, and so on), this
capability of emacs to be used as an IDE for RPM package
generation is extremely useful. Basic macros exist to do
complete builds (Ctrl+C B to build a binary package, Ctrl+C S to
build a source package, and Ctrl+C A to build both). Macros can
also be used to execute various intermediate steps, such as the
%prep stage (Ctrl+C P), the %build stage (Ctrl+C C), or the
%install stage (Ctrl+C I). Various options of the build process
can also be controlled, such as GPG-signing of generated
packages.
</para>
<para>
If you are a user of GNU Emacs or XEmacs, you should definitely
take the time to learn to use rpm-spec-mode. Being able to build
packages from within the editor where you are editing the spec
file that builds those packages is a great productivity gain for
many people.
</para>
</sect2>
<sect2>
<title>Validating and debugging spec files with rpmlint</title>
<para>
Both VIM and emacs extensions help with the process of initially
creating spec files and with the maintenance of existing RPM
spec files. After a spec file has been created, and RPMs have
been created using that spec, the binary RPMs generated from the
spec can be validated using the rpmlint command. The name
rpmlint comes from lint, the traditional Unix utility that can
"sanity-check" C source code, looking for certain classes of
common C coding mistakes. The idea behind rpmlint is similar; it
processes binary RPMs, checking for certain common mistakes made
by RPM packagers.
</para>
<para>
The rpmlint command currently ships with a wide variety of
checks and is written using a modular interface so that
additional checks can easily be added if needed. Currently,
rpmlint can check that all binary files in the package are
correct (making sure that a .noarch.rpm package does not contain
binary files, that no binaries are being installed in /etc, that
the binary file types in the package are appropriate for the
package architecture, that shared libraries are configured
correctly, and that all executables are stripped). It can also
check the validity of files marked as configuration files in the
RPM (ensuring that configuration files are only being installed
in /etc, not in /usr) and that the package file complies with
the distribution's policies for packages (checking things such
as the compression of man pages and Info pages and the
correctness of vendor and distribution fields in the package
header).
</para>
<para>
In addition, rpmlint performs a variety of checks to ensure that
the package complies with the Filesystem Hierarchy Standard
(verifying that files are installed in their standard locations
on the system), the Linux Standards Base (verifying that
package-file naming is LSB-compliant) and that files have
correct ownerships and permissions. Init scripts are
double-checked (for packages that have init scripts) to ensure
that the basic structure of the init script is correct and that
appropriate %post and %preun configuration directives are being
run to configure the init script on the system. %post, %pre, and
%preun scripts are also double-checked (ensuring that only valid
interpreters are specified for scripts and that scripts are
written in valid syntax). The validity of the package itself is
also checked in various ways (ensuring that the package is
GPG-signed, that the package's source RPM is correctly prepared,
that the package spec file uses correct syntax, and that all
tags used in the package header are valid).
</para>
<para>
Cross Reference
</para>
<para>
To find out more about the Filesystem Hierarchy Standard, see
www.pathname.com/fhs/. To find out more about the Linux
Standards Base, see www.linuxbase.org.
</para>
<para>
Download rpmlint from www.lepied.com/rpmlint. It is written
entirely in Python, so a Python interpreter is necessary to run
it.
</para>
<para>
Once installed, rpmlint can be configured on a system-wide
basis, using the /etc/rpmlint/config file, or on a per-user
basis, using the $HOME/.rpmlintrc file. This file can specify
checks to perform, check output that should be ignored, and
configuration options. Configuration options can be specified,
listing what entries are valid for various fields in the RPM
header, such as the Vendor and Packager fields. By default, Red
Hat Linux ships with this configuration file set to validate
packages to make sure they are suitable for Red Hat Linux; if
packaging for a different distribution, this file might need to
be modified.
</para>
<para>
Once rpmlint has been installed and configured, it can be run
against RPMs. For example, rpmlint helps with creating packages,
such as tin (a popular Usenet client) for Red Hat Linux, since
it is not included with the distribution. After preparing a tin
spec file, then building RPMs from that file, you can typically
double-check them using rpmlint.
</para>
<para>
For example, when running rpmlint on a source RPM, you���ll see
output like the following:
</para>
<para>
$ rpmlint tin-1.5.12-1.src.rpm
</para>
<para>
E: tin no-packager-tag
</para>
<para>
W: tin invalid-license distributable
</para>
<para>
W: tin no-url-tag
</para>
<para>
W: tin strange-permission tin-1.5.12.tar.bz2 0664
</para>
<para>
W: tin obsolete-tag Copyright
</para>
<para>
$
</para>
<para>
For the most part, this package looks fine according to the
rpmlint output. The permissions on the tin source code can be
changed (0644 is the "preferred" permissions), and you might
want to change my spec file to use the License tag instead of
the now-obsolete Copyright tag. Similarly, you might want to add
a URL tag to the package to point to the URL for the software.
</para>
<para>
When running rpmlint on a binary RPM, you���ll see output like
the following:
</para>
<para>
$ rpmlint tin-1.5.12-1.i386.rpm
</para>
<para>
W: tin invalid-vendor None
</para>
<para>
W: tin invalid-distribution None
</para>
<para>
E: tin no-packager-tag
</para>
<para>
W: tin invalid-license distributable
</para>
<para>
W: tin no-url-tag
</para>
<para>
$
</para>
<para>
With this output, the binary package looks fine. You should set
a I don���t bother setting a vendor, distribution, and packager
but you can ignore those warnings. Similarly, rpmlint warns
because it does not recognize the license type used,
"distributable". You can fix this, you can ignore this, or you
can modify /etc/rpmlint/config so that rpmlint recognizes
"distributable" as a valid license.
</para>
<para>
The sorts of validity checks that rpmlint can do make it
valuable for ensuring the quality and consistency of RPMs. Most
RPM-based Linux distributions validate their entire distribution
using rpmlint. Using it for packages you prepare is a good idea
as well.
</para>
</sect2>
<sect2>
<title>Generating the %files section with RUST</title>
<para>
For the most part, maintaining RPM spec files is relatively
straightforward. Creating spec files from scratch, however, can
be a little bit more challenging. Tools like rpm-spec-mode for
emacs can help with the process, generating skeleton spec file
templates that can be filled in, but these sorts of tools do not
address the step that most new RPM packagers seem to find most
difficult: generating the %files section. Creating a complete,
accurate list of all needed files supplied by an application can
be difficult, particularly when it is an application with which
you are unfamiliar. Most software supports installation to a
temporary location; if the software you are packaging allows
this, generation of %files is (almost) as simple as using
BuildRoot to install the application to a temporary directory,
then running an ls -lR command in that subdirectory to see all
the installed files and directories. Even then, though, the
output from ls -lR must be cleaned up and converted into %files
format for adding to the spec file. All of this takes time.
</para>
<para>
A couple of tools exist to reduce the amount of work needed for
this stage of the process, automating the generation of the
%files section of spec files. The most sophisticated of these
toolsets is RUST.
</para>
<para>
Cross Reference
</para>
<para>
Download RUST from www.rusthq.com.
</para>
<para>
RUST consists of two tools: crust and rust. The crust command
provides a command-line tool that can create a chroot() jail, in
which software can be built and installed, and then
automatically generate a spec file that documents the files that
were installed. This not only eliminates the need to generate a
%files section for a spec file manually but also removes the
need to modify software to support installation to a temporary
location using BuildRoot, a sometimes difficult task.
</para>
<para>
The rust command provides a graphical front end to the crust
command, as shown in Figure 13-3.
</para>
<para>
54965-0 Fg1303.tiff here
</para>
<para>
Figure 13-3: rust, a drag-and-drop spec file generator
</para>
<para>
The rust command provides a graphical interface that can be used
to control crust and supports drag-and-drop creation of spec
files. In the rust interface, two file trees are displayed. The
left-hand tree displays the local file system, while the
right-hand tree displays the file tree inside the crust chroot()
jail. Files that should be packaged together can just be dragged
from their current locations on the system (displayed in the
left-hand tree) to their final destinations in the right-hand
tree. You can then click the makeRPM choice to generate an RPM
containing those files. Although not terribly useful for
packages being generated from source code, this feature can
greatly simplify creation of RPMs of applications that are only
supplied in binary format (such as the Linux Adobe Acrobat
reader).
</para>
<para>
RUST's rust application can be useful in some circumstances
(providing new developers a graphical tool that can be used to
generate binary RPMs), and crust is more generally useful for
packaging difficult-to-package software that needs to be built
and installed in a chroot() jail. Unfortunately, development of
RUST appears to have stopped, so extension of RUST to become a
more generally useful IDE for RPM generation is not likely to
happen. However, the project is licensed under the GNU GPL
(Appendix G), so it might be resumed by another developer or
team of developers.
</para>
</sect2>
<sect2>
<title>setup.sh and MakeRPM.pl</title>
<para>
Other tools that have been developed to simplify the process of
creating an RPM spec file take an entirely different approach.
Tools such as setup.sh, available from
www.mmedia.is/~bre/programs/setup.sh, are intended to function
as wrappers around the existing build commands (./configure and
make) for software. These types of tools take the approach of
using the standard build tools for software (since those tools
must always be used to build the software, whether using RPM or
compiling the software from a source tarball) and capturing the
output to generate an RPM spec file automatically.
</para>
<para>
The MakeRPM.pl Perl script, available from
www.perl.com/CPAN/modules/by-authors/id/JWIED, is another
example of such an approach. MakeRPM.pl is a more specialized
tool than setup.sh, as MakeRPM.pl is intended only for producing
RPMs from Perl modules packaged in CPAN (www.cpan.org). It is
implemented as a wrapper around the standard commands (perl
Makefile.PL ; make ; make test ; make install) used to install
Perl CPAN software.
</para>
<para>
MakeRPM.pl actually works quite well for its intended
purpose@mdproducing packages of CPAN modules. The setup.sh
script is currently viewable mainly as a proof of concept,
rather than being a generally universal automatic spec file
generator. In the future, when spec files are likely to be
representable using a formal closed-syntax grammar, it is
possible that more generalized spec file generation tools will
be developed. Until that time, however, some of the previously
mentioned tools, particularly the VIM and emacs extensions, can
provide assistance when manually generating spec files.
</para>
<para>
Cross-reference
</para>
<para>
For more discussion of the future of RPM, you can turn to
Chapter 22.
</para>
</sect2>
<sect2>
<title>Manipulating Package Files with rpm2cpio</title>
<para>
Normally, RPM packagers are concerned with taking source code or
binary files, and producing an RPM that contains those files and
can be used to install them on end-users' systems. Sometimes,
packagers and end users find themselves in the opposite
position, that of having a source or binary RPM package file and
needing to extract its contents. An RPM can always be installed
to access its contents (either source code, patches, and a spec
file which get put under %_topdir for a source RPM, or software
which gets put in system directories for a binary RPM), but that
is often overkill. I frequently want to extract a single patch
file, or the spec file, from a source RPM, but I don't really
need to install the entire source RPM. Similarly, people often
want to extract the contents of RPMs on systems that do not come
with RPM, such as Solaris.
</para>
<para>
Fortunately, tools are available that can process RPM package
files into a format from which their content can be extracted.
Structurally speaking, RPM package files are compressed cpio
archives that have additional binary data added to the beginning
containing various meta-data about the package (specifying its
architecture and OS, for example), a GPG signature if the
package is signed, and so forth. If this binary data is removed
from the beginning of the RPM package file, the remainder is a
System V Release 4-style cpio file that can be manipulated using
any reasonably complete cpio command. Several different tools,
each sporting the name rpm2cpio, are available which can do this
binary data removal, converting an RPM package file into a
standard cpio archive.
</para>
<para>
RPM ships with an rpm2cpio utility that can be used to convert
RPM package files to cpio files. (Chapter 3 introduces the
rpm2cpio utility.) For example, if you have a source RPM package
file and want to extract its files without having to install it,
you can process it through rpm2cpio. The rpm2cpio command takes
as input an RPM package file, and produces a cpio file on
standard output. For example, to redirect the output to a file,
use a command like the following:
</para>
<para>
$ rpm2cpio fluxbox-0.1.8-2.src.rpm > fluxbox-0.1.8-2.cpio
</para>
<para>
$
</para>
<para>
This command creates a cpio archive from the package. You can
later use cpio commands on the output file. You can also pipe
the output of rpm2cpio through the cpio command:
</para>
<para>
$ rpm2cpio fluxbox-0.1.8-2.src.rpm | cpio -i -d
</para>
<para>
656 blocks
</para>
<para>
$
</para>
<para>
This command extracts the contents of the package.
</para>
<para>
This rpm2cpio command is bundled with RPM and is installed on
most RPM-based Linux distributions, including Red Hat Linux.
However, it is less useful on systems that do not come with RPM,
such as Solaris. This "standard" implementation of rpm2cpio is
written in C, and so must be compiled before it can be used.
Since most commercial Unix systems do not come with a C compiler
by default (unlike Linux and other free Unixes, such as the BSD
operating systems), compiling this rpm2cpio code can be a major
undertaking.
</para>
<para>
Fortunately, rpm2cpio implementations are also available in a
couple of other languages, in more easy-to-install formats for
other operating sytsems, including as a Bourne shell script or a
Perl script. The Bourne shell syntax should work on any
reasonably modern Unix system (and even a few non-Unix systems;
it also works on Microsoft Windows under cygwin, for example).
The script in Listing 13-1should be saved to a file named
rpm2cpio.sh, marked executable, and copied to a directory in
your path.
</para>
<para>
Listing 13-1: rpm2cpio as a Bourne Shell script
</para>
<para>
#!/bin/sh
</para>
<para/>
<para>
pkg=$1
</para>
<para>
if [ "$pkg" = "" -o ! -e "$pkg" ]; then
</para>
<para>
echo "no package supplied" 1>&2
</para>
<para>
exit 1
</para>
<para>
fi
</para>
<para/>
<para>
leadsize=96
</para>
<para>
o=`expr $leadsize + 8`
</para>
<para>
set `od -j $o -N 8 -t u1 $pkg`
</para>
<para>
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
</para>
<para>
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
</para>
<para>
# echo "sig il: $il dl: $dl"
</para>
<para/>
<para>
sigsize=`expr 8 + 16 \* $il + $dl`
</para>
<para>
o=`expr $o + $sigsize + \( 8 - \( $sigsize \% 8 \) \) \% 8 + 8`
</para>
<para>
set `od -j $o -N 8 -t u1 $pkg`
</para>
<para>
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
</para>
<para>
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
</para>
<para>
# echo "hdr il: $il dl: $dl"
</para>
<para/>
<para>
hdrsize=`expr 8 + 16 \* $il + $dl`
</para>
<para>
o=`expr $o + $hdrsize`
</para>
<para/>
<para>
dd if=$pkg ibs=$o skip=1 2>/dev/null | gunzip
</para>
<para>
After you have marked this file as executable and placed it in
your command path, you can use the script just like the C
language implementation of rpm2cpio. This script also takes an
RPM package file as input and produces a cpio file on standard
output, and so should be used in conjunction with redirection or
a pipe:
</para>
<para>
$ rpm2cpio.sh fluxbox-0.1.8-2.src.rpm | cpio -i -d
</para>
<para>
656 blocks
</para>
<para>
$
</para>
<para>
In this case, I piped the output to cpio, directly extracting
it. I could have redirected the output of rpm2cpio.sh to a file
instead.
</para>
<para>
In addition to the Bourne shell implementation of rpm2cpio, a
version has been written in Perl by Roger Espel Llima. The Perl
rpm2cpio implementation should work on any system that has a
reasonably modern Perl interpreter. To use this version of
rpm2cpio, the script in Listing 13-2 should be saved to a file
named rpm2cpio.pl, marked executable, and copied to a directory
in your path.
</para>
<para>
Listing 13-2:The Perl version of rpm2cpio, rpm2cpio.pl
</para>
<para>
#!/usr/bin/perl
</para>
<para/>
<para>
# Copyright (C) 1997,1998,1999, Roger Espel Llima
</para>
<para>
#
</para>
<para>
# Permission is hereby granted, free of charge, to any person
obtaining a copy
</para>
<para>
# of this software and any associated documentation files (the
"Software"), to
</para>
<para>
# deal in the Software without restriction, including without
limitation the
</para>
<para>
# rights to use, copy, modify, merge, publish, distribute,
sublicense,
</para>
<para>
# and/or sell copies of the Software, and to permit persons to
whom the
</para>
<para>
# Software is furnished to do so, subject to the following
conditions:
</para>
<para>
#
</para>
<para>
# The above copyright notice and this permission notice shall be
included in
</para>
<para>
# all copies or substantial portions of the Software.
</para>
<para>
#
</para>
<para>
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR
</para>
<para>
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
</para>
<para>
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE
</para>
<para>
# SOFTWARE'S COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER
</para>
<para>
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM,
</para>
<para>
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
</para>
<para>
# THE SOFTWARE
</para>
<para/>
<para>
# (whew, that's done!)
</para>
<para/>
<para>
# why does the world need another rpm2cpio? because the existing
one
</para>
<para>
# won't build unless you have half a ton of things that aren't
really
</para>
<para>
# required for it, since it uses the same library used to
extract RPM's.
</para>
<para>
# in particular, it won't build on the HPsUX box i'm on.
</para>
<para/>
<para>
# sw 2002-Mar-6 Don't slurp the whole file
</para>
<para/>
<para>
# add a path if desired
</para>
<para>
$gzip = "gzip";
</para>
<para/>
<para>
sub printhelp {
</para>
<para>
print <<HERE;
</para>
<para>
rpm2cpio, perl version by orabidoo <odar\(a)pobox.com> +sw
</para>
<para>
dumps the contents to stdout as a cpio archive
</para>
<para/>
<para>
use: rpm2cpio [file.rpm] > file.cpio
</para>
<para/>
<para>
Here's how to use cpio:
</para>
<para>
list of contents: cpio -t -i < /file/name
</para>
<para>
extract files: cpio -d -i < /file/name
</para>
<para>
HERE
</para>
<para/>
<para>
exit 0;
</para>
<para>
}
</para>
<para/>
<para>
if ($#ARGV == -1) {
</para>
<para>
printhelp if -t STDIN;
</para>
<para>
$f = "STDIN";
</para>
<para>
} elsif ($#ARGV == 0) {
</para>
<para>
open(F, "< $ARGV[0]") or die "Can't read file $ARGV[0]\n";
</para>
<para>
$f = 'F';
</para>
<para>
} else {
</para>
<para>
printhelp;
</para>
<para>
}
</para>
<para/>
<para>
printhelp if -t STDOUT;
</para>
<para/>
<para>
# gobble the file up
</para>
<para>
##undef $/;
</para>
<para>
##$|=1;
</para>
<para>
##$rpm = <$f>;
</para>
<para>
##close ($f);
</para>
<para/>
<para>
read $f,$rpm,96;
</para>
<para/>
<para>
($magic, $major, $minor, $crap) = unpack("NCC C90", $rpm);
</para>
<para/>
<para>
die "Not an RPM\n" if $magic != 0xedabeedb;
</para>
<para>
die "Not a version 3 or 4 RPM\n" if $major != 3 &&
$major != 4;
</para>
<para/>
<para>
##$rpm = substr($rpm, 96);
</para>
<para/>
<para>
while (!eof($f)) {
</para>
<para>
$pos = tell($f);
</para>
<para>
read $f,$rpm,16;
</para>
<para>
$smagic = unpack("n", $rpm);
</para>
<para>
last if $smagic eq 0x1f8b;
</para>
<para>
# Turns out that every header except the start of the gzip one
is
</para>
<para>
# padded to an 8 bytes boundary.
</para>
<para>
if ($pos & 0x7) {
</para>
<para>
$pos += 7;
</para>
<para>
$pos &= ~0x7;# Round to 8 byte boundary
</para>
<para>
seek $f, $pos, 0;
</para>
<para>
read $f,$rpm,16;
</para>
<para>
}
</para>
<para>
($magic, $crap, $sections, $bytes) = unpack("N4", $rpm);
</para>
<para>
die "Error: header not recognized\n" if $magic != 0x8eade801;
</para>
<para>
$pos += 16;# for header
</para>
<para>
$pos += 16 * $sections;
</para>
<para>
$pos += $bytes;
</para>
<para>
seek $f, $pos, 0;
</para>
<para>
}
</para>
<para/>
<para>
if (eof($f)) {
</para>
<para>
die "bogus RPM\n";
</para>
<para>
}
</para>
<para/>
<para>
open(ZCAT, "|gzip -cd") || die "can't pipe to gzip\n";
</para>
<para>
print STDERR "CPIO archive found!\n";
</para>
<para/>
<para>
print ZCAT $rpm;
</para>
<para/>
<para>
while (read($f, ($_=''), 16384) > 0) {
</para>
<para>
print ZCAT;
</para>
<para>
}
</para>
<para/>
<para>
close ZCAT;
</para>
<para>
After set up, rpm2cpio.pl works much like the C and Bourne shell
versions, so the following command can be used to generate a
cpio archive from an RPM package file:
</para>
<para>
$ rpm2cpio.pl fluxbox-0.1.8-2.src.rpm | cpio -i -d
</para>
<para>
CPIO archive found!
</para>
<para>
656 blocks
</para>
<para>
$
</para>
<para/>
<para>
Depending upon the system you are on, one or more of these three
rpm2cpio programs should work. All three are useful any time you
want to extract a file or files from an RPM package file but do
not actually need to install the RPM.
</para>
</sect2>
</sect1>
<sect1>
<title>Summary</title>
<para>
Creating RPM spec files and maintaining those files can be a
difficult chore. A number of tools and add-ons for text editors
have sprung up to help make this less of a chore.
</para>
<para>
Users of the two most common Linux text editors, vi and emacs, can
use add-ons that understand the RPM spec file syntax. These
add-ons help reduce errors and, though the use of macros, can
speed development of spec files by automating some of the tasks.
</para>
<para>
The RUST tool provides a graphical interface for creating spec
files that can simplify a lot of the work normally required.
</para>
<para>
Once you���ve created an RPM package, you can use the rpmlint
command to flag missing, incomplete, or incorrect elements in your
RPMs.
</para>
<para>
Another tool, called rpm2cpio in its various incarnations, allows
you to extract files from an RPM package by taking advantage of
the fact that RPM files use the cpio format internally. The
rpm2cpio tools can output RPM data into the cpio format directly;
you can then pipe the output to the cpio command to extract.
</para>
<para>
After all this help in making RPMs and spec files, the next
chapter covers a set of best-practice guidelines to help avoid
problems when making your RPMs.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv521
Added Files:
rpm-guide-en.xml
Log Message:
--- NEW FILE rpm-guide-en.xml ---
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../docs-common/common/fedora-entities-en.ent">
%FEDORA-ENTITIES-EN;
<!ENTITY VERSION "1.0"> <!-- version for this document -->
<!ENTITY BOOKID "rpm-guide-en-&VERSION; (2005-10-03-T23:30+01:00)"> <!-- change date here and VERSION entity everytime a change is made-->
<!ENTITY LEGALNOTICE SYSTEM "../docs-common/common/legalnotice-en.xml">
<!-- Bugzilla bug number for the draft notice -->
<!ENTITY BUG-NUM "1000000">
<!ENTITY DOCLOCALVER "0.1">
<!ENTITY DRAFTNOTICE SYSTEM "../docs-common/common/draftnotice-en.xml">
<!ENTITY PACKAGINGINTRO SYSTEM "rpm-guide-intro-packaging-en.xml">
<!ENTITY RPMINTRO SYSTEM "rpm-guide-intro-rpm-en.xml">
<!ENTITY RPMOVERVIEW SYSTEM "rpm-guide-rpm-overview-en.xml">
<!ENTITY USINGRPM SYSTEM "rpm-guide-using-rpm-en.xml">
<!ENTITY USINGRPMDB SYSTEM "rpm-guide-using-rpm-db-en.xml">
<!ENTITY DEPENDENCIES SYSTEM "rpm-guide-dependencies-en.xml">
<!ENTITY TRANSACTIONS SYSTEM "rpm-guide-transactions-en.xml">
<!ENTITY MANAGEMENT SYSTEM "rpm-guide-management-software-en.xml">
<!ENTITY CREATING SYSTEM "rpm-guide-creating-rpms-en.xml">
<!ENTITY SPECFILES SYSTEM "rpm-guide-specfiles-en.xml">
<!ENTITY ADVPACKAGING SYSTEM "rpm-guide-advanced-packaging-en.xml">
<!ENTITY RPMBUILD SYSTEM "rpm-guide-rpmbuild-en.xml">
<!ENTITY PACKAGINGTOOLS SYSTEM "rpm-guide-extra-packaging-tools-en.xml">
<!ENTITY GUIDELINES SYSTEM "rpm-guide-packaging-guidelines-en.xml">
<!ENTITY SCRIPTING SYSTEM "rpm-guide-scripting-en.xml">
<!ENTITY PROGRAMMINGC SYSTEM "rpm-guide-programming-c-en.xml">
<!ENTITY PROGRAMMINGPY SYSTEM "rpm-guide-programming-python-en.xml">
<!ENTITY PROGRAMMINGPL SYSTEM "rpm-guide-programming-perl-en.xml">
<!ENTITY OTHERLINUXES SYSTEM "rpm-guide-other-linuxes-en.xml">
<!ENTITY OTHEROS SYSTEM "rpm-guide-other-os-en.xml">
<!ENTITY CUSTOMIZINGRPM SYSTEM "rpm-guide-customizing-rpm-en.xml">
<!ENTITY COMMANDREF SYSTEM "rpm-guide-command-reference-en.xml">
<!ENTITY SPECFILESYN SYSTEM "rpm-guide-specfile-syntax-en.xml">
<!ENTITY RPMEVOLUTION SYSTEM "rpm-guide-rpm-evolution-en.xml">
<!ENTITY RPMSTRUCTURE SYSTEM "rpm-guide-package-structure-en.xml">
<!ENTITY RESOURCES SYSTEM "rpm-guide-online-resources-en.xml">
<!ENTITY DEVTOOLS SYSTEM "rpm-guide-development-tools-en.xml">
<!ENTITY LICENSING SYSTEM "rpm-guide-licensing-en.xml">
]>
<book id="book" lang="en">
<bookinfo>
<title>RPM Guide</title>
<!-- Remove DOCLOCALVER for release -->
<copyright>
<year>2005</year>
<holder>Eric Foster-Johnson</holder>
</copyright>
<authorgroup>
<author>
<surname>Foster-Johnson</surname>
<firstname>Eric</firstname>
</author>
</authorgroup>
&LEGALNOTICE;
<revhistory>
<revision>
<revnumber>0.1</revnumber>
<date>2005-10-03</date>
<authorinitials>StuartEllis</authorinitials>
<revdescription>
<para>
First commission to CVS
</para>
</revdescription>
</revision>
</revhistory>
</bookinfo>
&PACKAGINGINTRO;
&RPMINTRO;
&RPMOVERVIEW;
&USINGRPM;
&USINGRPMDB;
&DEPENDENCIES;
&TRANSACTIONS;
&MANAGEMENT;
&CREATING;
&SPECFILES;
&ADVPACKAGING;
&RPMBUILD;
&PACKAGINGTOOLS;
&GUIDELINES;
&SCRIPTING;
&PROGRAMMINGC;
&PROGRAMMINGPY;
&PROGRAMMINGPL;
&OTHERLINUXES;
&OTHEROS;
&CUSTOMIZINGRPM;
&COMMANDREF;
&SPECFILESYN;
&RPMEVOLUTION;
&RPMSTRUCTURE;
&RESOURCES;
&DEVTOOLS;
&LICENSING;
<index id="generated-index">
</index>
</book>
<!--
Local variables:
mode: xml
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-development-tools-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv492
Added Files:
rpm-guide-development-tools-en.xml
Log Message:
--- NEW FILE rpm-guide-development-tools-en.xml ---
<!-- $Id: -->
<chapter id="ch-development-tools">
<title>Linux Text Editors and Development Tools</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Appendix
</para>
<para>
*General text editors
</para>
<para>
*C-specific tools and integrated development environments
</para>
<para>
*Python-specific development tools
</para>
<para>
Linux includes a number of text editors and integrated development
environments (IDEs), going from plain old text editors all the way
up to sophisticated tools. These tools are suitable for shell
scripting, C, Python, and Perl programming, along with a plethora of
other uses. Linux makes extensive use of text files, especially for
configuration data, so Linux has always included a number of text
editors.
</para>
<para>
This appendix lists a number of tools for those who have not yet set
up an RPM development environment on Linux. Note that choosing an
editor or IDE is mostly a matter of personal taste. Programmers will
often engage in raging battles over the superiority of text editors
and other programming tools. Before searching around too far, try
out what you have installed on your system and see if that works for
you.
</para>
<para>
Note that Internet sites may change or disappear, so you may have to
search to find these tools.
</para>
<sect1>
<title>General Text Editors</title>
<para>
Linux distributions include a number of text editors with varying
sets of features. The two most common editors are vi and emacs,
which come with virtually all Linux distributions. These editors
are good for UNIX- or Linux-savvy developers, but generally have a
steep learning curve for developers used only to Windows.
</para>
<para>
If you come from Windows, try gedit, kedit, or kate. These text
editors open a graphical window on your desktop, making them
appear more or less like the Windows Notepad.exe. All three offer
more features than Notepad.exe, however.
</para>
<para>
You may not have installed any of these editors, but all are
available as part of Red Hat Linux. You can install vi, emacs,
gedit, kedit, or kate from the packages that come with your Linux
distribution.
</para>
<para>
To start one of the editors, enter a command like the following:
</para>
<para>
$ gedit listrpmpkgs &
</para>
<para>
The ampersand, &, launches the program in the background.
Replace gedit with the editor you choose.
</para>
</sect1>
<sect1>
<title>Programming Text Editors</title>
<para>
In addition to general-purpose text editors, Linux sports a large
number of text editors with special features for programming, such
as syntax highlighting. The extended version of vi, called vim,
includes a number of add-ons that can help you with C programming
tasks. Emacs also includes a wide array of features to help
programming. Both of these editors can act as development
environments with a bit of configuration. As mentioned previously,
both come with most Linux distributions.
</para>
<para>
I also like an editor called nedit and another one called jedit.
The jedit editor is written in Java, so that it runs the same on
Windows and Linux, a big win if you must work on multiple
platforms. (Emacs and vim have versions that work on Windows, too,
along with Linux.) If you use jedit, you must have a Java runtime
environment installed.
</para>
<para>
Cross Reference
</para>
<para>
Download nedit from www.nedit.org. Download jedit from
www.jedit.org. Download Java runtime environments from Sun at
http://java.sun.com/j2se/downloads.html or IBM at
www.ibm.com/java/jdk/ and select the IBM Developer Kit for Linux.
</para>
</sect1>
<sect1>
<title>Integrated Development Environments for C Programming</title>
<para>
If you want more of a graphical environment, Red Hat Linux ships
with KDevelop, an IDE for C and C++ programming.
</para>
<para>
Anjuta provides a GTK/GNOME-based IDE, an alternative to the
KDE-based KDevelop. KDevelop, however, supports KDE, GNOME, Qt,
and text-mode C and C++ applications.
</para>
<para>
Cross Reference
</para>
<para>
Download Anjuta from www.anjuta.org.
</para>
<para>
The Eclipse IDE, while mostly used for Java development, has a C
and C++ mode called CDT, for C/C++ Development Tools. Eclipse is
important because Red Hat provides an RPM-building plug-in to
Eclipse.
</para>
<para>
Cross Reference
</para>
<para>
Download Anjuta from www.anjuta.org. Download Eclipse from
www.eclipse.org and the Eclipse CDT from
www.eclipse.org/tools/downloads.html.
</para>
</sect1>
<sect1>
<title>Integrated Development Environments for Python Programming</title>
<para>
As with C programs, Python scripts are made up of text files
holding Python commands, so you need a text editor or some sort of
development environment for creating Python programs. Any of the
tools listed so far will work fine for developing Python
applications. The key requirement is the ability to control tabs
and indenting, since this is crucial to Python syntax.
</para>
<para>
IDLE, a graphical console and editor, supports creating Python
applications. This is considered part of Python. IDLE requires the
Python-tools package.
</para>
<para>
In addition, you can choose from Python-focused tools such as
Bicycle Repair Man, a refactoring tool, or Boa Constructor and
Black Adder, two Python IDEs.
</para>
<para>
Cross Reference
</para>
<para>
Boa Constructor is available from
http://boa-constructor.sourceforge.net. Black Adder is a
commercial tool available at www.thekompany.com.
</para>
<para>
The Eclipse IDE, mentioned previously, supports a number of Python
add-ons. Combined with the C and C++ tools, and plug-ins for
building RPMs, Eclipse brings together most everything you need
for Python development on Linux.
</para>
<para>
Cross Reference
</para>
<para>
Eclipse is available at www.eclipse.org, and Python add-ons at
http://sourceforge.net/projects/pyeclipse,
http://sourceforge.net/projects/pe4eclipse, or
http://www.kalab.com/freeware/pythoneclipse/pythoneclipse.htm.
</para>
<para>
This is really just the tip of the iceberg when it comes to Python
tools. You can find many more available on the Internet.
</para>
<para>
Cross Reference
</para>
<para>
A large listing of Python editing tools appears at
http://www.python.org/cgi-bin/moinmoin/PythonEditors.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months
rpm-guide rpm-guide-dependencies-en.xml,NONE,1.1
by fedora-docs-commits@redhat.com
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv463
Added Files:
rpm-guide-dependencies-en.xml
Log Message:
--- NEW FILE rpm-guide-dependencies-en.xml ---
<!-- $Id: -->
<chapter id="ch-dependencies">
<title>Package Dependencies</title>
<para>
In This Chapter
</para>
<para>
*Understanding dependencies
</para>
<para>
*Package capabilities
</para>
<para>
*Version dependencies
</para>
<para>
*Checking dependencies
</para>
<para>
*Triggers
</para>
<para>
Packages aren���t built in a vacuum. Web applications, for example,
build on system networking libraries, system-encryption libraries,
and system-file input and output libraries.
</para>
<para>
This chapter covers dependencies between packages, along with ways
to discover and manage those dependencies.
</para>
<sect1>
<title>Understanding the Dependency Concept</title>
<para>
A dependency occurs when one package depends on another. You might
think it would make for an easier-to-manage system if no package
depended on any others, but you���d face a few problems, not the
least of which would be dramatically increased disk usage.
</para>
<para>
Packages on your Linux system depend on other packages. Just about
every package with an application, for example, depends on the
system C libraries, since these libraries provide common
facilities that just about every program uses. Network
applications typically depend on low-level networking libraries.
These dependencies really work in your favor, since a security bug
fix in the network libraries can update all applications that make
use of the updated libraries.
</para>
<para>
Furthermore, sharing software means that each package has less
code to maintain and thus improved quality. Code sharing has been
in the computer lexicon since the 1960s.
</para>
<para>
Although quite a few packages depend on system-level libraries,
some packages depend on applications defined in other packages.
The Emacs text editor package, for example, depends on the Perl
scripting language, specifically, the perl command. Database
client programs usually depend on the database server
applications.
</para>
<para>
The RPM database tracks dependency information, so it can, for
example, stop attempts to remove packages that other packages
depend on or inform users of dependent packages upon installation.
</para>
<sect2>
<title>Capabilities</title>
<para>
In RPM terminology, each package provides capabilities. A
capability is simply a text string that the package claims it
provides. In most cases, a capability names a file or a package.
But the capability can be any arbitrary text string.
</para>
<para>
Other packages can then depend on certain capabilities. (You can
use this concept in building your own packages.) Each package
lists the capabilities it requires as well as the capabilities
it provides.
</para>
<para>
Cross Reference
</para>
<para>
Package dependencies and capabilities are very important when
creating spec files for building your own RPM packages, the
subject of Chapter 10.
</para>
<para>
When you install a package, the capability information is stored
in the RPM database. When you remove a package, the rpm command
checks the RPM database. If the package you are trying to remove
provides a capability that another package needs, the command
will generate an error. If you try to remove a package that
other packages depend on, you'll see an error like the
following:
</para>
<para>
# rpm -e setup
</para>
<para>
error: Failed dependencies:
</para>
<para>
setup is needed by (installed) basesystem-8.0-1
</para>
<para>
setup >= 2.0.3 is needed by (installed) initscripts-6.95-1
</para>
<para>
setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5
</para>
<para>
setup is needed by (installed) xinetd-2.3.7-2
</para>
<para>
setup is needed by (installed) dump-0.4b28-4
</para>
<para>
To verify that the package has not been removed, you can query
for the package after trying to remove it, as shown following:
</para>
<para>
# rpm -q setup
</para>
<para>
setup-2.5.20-1
</para>
<para>
This shows that the rpm command has not removed the setup
package due to the errors.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 4 covers ways to force the rpm command to do what you
want, although this can cause problems if you try to force the
issue and remove a crucial package. In virtually all cases, do
not use any of the force options, as this can cause problems
with the RPM system, since the force options are purposely
ignoring safety checks performed by the rpm command.
</para>
<para>
Many capabilities that packages require are system libraries,
especially shared libraries. Shared libraries, which usually
have a .so file extension (short for shared object), provide a
memory-efficient means for applications to share program code.
These libraries may also have a .so.number extension, such as
libc.so.6.
</para>
<para>
Note
</para>
<para>
Shared libraries on Windows are called DLLs, short for Dynamic
Link Libraries. The implementations differ, but the Windows DLL
concept is similar to Linux and Unix shared objects.
</para>
<para>
Shared libraries have been part of Linux for a long time and
have nothing to do with the RPM system. Shared libraries
accessed by a program, however, represent natural dependencies.
Because so many programs depend on shared libraries, the RPM
system can automatically handle many shared-library
dependencies.
</para>
<para>
Note
</para>
<para>
To list the shared libraries that a program accesses, use the
ldd command, for example:
</para>
<para>
$ ldd /bin/grep
</para>
<para>
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
</para>
<para>
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
</para>
<para>
Other dependencies include version-specific dependencies.
</para>
</sect2>
<sect2>
<title>Version dependencies</title>
<para>
An application may depend on a capability provided by another
package. It may also depend on the capability that a specific
version of another package provides. For example, some add-ons
to the Apache Web server depend on the version of Apache. The
Apache 2.0 version made a number of changes that affect add-on
packages. Some Apache add-on packages depend on version 1.3;
others depend on version 2.0.
</para>
<para>
Most package dependencies assume some level of compatibility and
require a version at or above a given version number (for
example, version 2.0 or later).
</para>
<para>
Note
</para>
<para>
You���ll see more version dependencies when applications make
major changes, such as the change from 1.3 to 2.0 for the Apache
Web server.
</para>
</sect2>
<sect2>
<title>Conflicts</title>
<para>
Some packages may provide capabilities that interfere with those
in other packages. This is called a conflict. Installing
conflicting packages is an error. For example, the httpd package
(the Apache Web server) conflicts with the thttpd package. Both
packages want to provide the primary Web server for a system.
</para>
<para>
The RPM system will prevent you from installing packages that
conflict with other packages. You can force the issue, using the
techniques described in Chapter 4, and override the RPM system.
But in most cases, you should not install packages that
conflict.
</para>
</sect2>
<sect2>
<title>Obsoletes</title>
<para>
The RPM system supports one more type of dependency, called
obsoletes. This refers to a capability that a package provides
that makes another capability obsolete. For example, a new
version of the perl interpreter may make an older version
obsolete. In most cases, the obsoletes dependency should be used
when the name of a package changes. For example, the apache Web
server package became the httpd package. You would expect the
new package, httpd, to obsolete the old package name, apache.
</para>
<para>
This brings the total to four types of dependencies that the RPM
system tracks:
</para>
<para>
*Requires, which tracks the capabilities a package requires
</para>
<para>
*Provides, which tracks the capabilities a package provides for
other packages
</para>
<para>
*Conflicts, which describes the capabilities that if installed,
conflict with capabilities in a package
</para>
<para>
*Obsoletes, which describes the capabilities that this package
will make obsolete
</para>
<para>
Packages advertise this dependency information. Each dependency
holds the type, such as requires, a capability, such as a shared
library or a package name, and optionally a version number, such
as requiring the python package at a version number greater than
or equal to 2.2 (python >= 2.2).
</para>
<para/>
<para>
You can check package dependencies by using, as you���d guess,
the rpm command.
</para>
</sect2>
</sect1>
<sect1>
<title>Checking for Dependencies</title>
<para>
The rpm ���q command queries the RPM database or RPM package
files. With the right options to this command, you can check for
the four types of package dependencies as well. These options are
based on the concept of capabilities introduced previously.
</para>
<para>
You can query what capabilities a package requires. You can also
query what capabilities a package provides. You can query for the
obsoleting and conflicting information as well. Furthermore, given
a capability, you can query which packages require this capability
as well as which packages provide this capability.
</para>
<para>
Cross Reference
</para>
<para>
There are quite a few more options you can use with the rpm ���q
command for querying packages. See Chapter 5 for more on querying
packages and package files.
</para>
<sect2>
<title>Determining the capabilities a package requires</title>
<para>
The first and most important step is to determine what
capabilities a package requires. If all the required
capabilities are met, you can safely install the package
(barring other things that can go wrong, such as conflicts). The
requires dependencies are by far the most important.
</para>
<para>
The --requires option to the rpm ���q command lists the
capabilities a given package requires. The basic syntax is:
</para>
<para>
rpm ���q query_options --requires packages
</para>
<para>
For example:
</para>
<para>
$ rpm -qp --requires sendmail-8.12.5-7.i386.rpm
</para>
<para>
/usr/sbin/alternatives
</para>
<para>
rpmlib(VersionedDependencies) <= 3.0.3-1
</para>
<para>
chkconfig >= 1.3
</para>
<para>
/usr/sbin/useradd
</para>
<para>
/bin/mktemp
</para>
<para>
fileutils
</para>
<para>
gawk
</para>
<para>
sed
</para>
<para>
sh-utils
</para>
<para>
procmail
</para>
<para>
bash >= 2.0
</para>
<para>
/bin/sh
</para>
<para>
/bin/sh
</para>
<para>
/bin/sh
</para>
<para>
/bin/sh
</para>
<para>
/bin/sh
</para>
<para>
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
</para>
<para>
rpmlib(CompressedFileNames) <= 3.0.4-1
</para>
<para>
/bin/bash
</para>
<para>
libcrypto.so.2
</para>
<para>
libcrypt.so.1
</para>
<para>
libc.so.6
</para>
<para>
libc.so.6(GLIBC_2.0)
</para>
<para>
libc.so.6(GLIBC_2.1)
</para>
<para>
libc.so.6(GLIBC_2.1.3)
</para>
<para>
libc.so.6(GLIBC_2.2)
</para>
<para>
libdb-4.0.so
</para>
<para>
libgdbm.so.2
</para>
<para>
libhesiod.so.0
</para>
<para>
liblber.so.2
</para>
<para>
libldap.so.2
</para>
<para>
libnsl.so.1
</para>
<para>
libnsl.so.1(GLIBC_2.0)
</para>
<para>
libresolv.so.2
</para>
<para>
libresolv.so.2(GLIBC_2.0)
</para>
<para>
libresolv.so.2(GLIBC_2.2)
</para>
<para>
libsasl.so.7
</para>
<para>
libssl.so.2
</para>
<para>
This example tests an RPM package file,
sendmail-8.12.5-7.i386.rpm, for the requires dependency, in
other words, what capabilities the package requires. The
sendmail package depends on a lot of other parts of the system,
as you can see in the response to the command shown previously.
Most of the dependencies are for system libraries (all the
dependencies ending in .so or .so.number). This package requires
other capabilities (packages in this case). It also requires the
chkconfig package at a specific version, version 1.3 or higher,
and the bash package at version 2.0 or higher. The sendmail
package also requires a particular version of the RPM system
(the rpmlib dependency).
</para>
<para>
Warning
</para>
<para>
Always check what a package requires before installing the
package. You can also use the --test option when trying to
install the package to first test whether the installation can
proceed. See Chapter 4 for details on installing packages and
the --test option. The rpm command will perform all these checks
for you anyway. Checking in advance, though, with the --test
option, helps avoid dependency hell with circular dependencies.
</para>
<para>
You can also check for what an installed package requires with
the --requires option. For example:
</para>
<para>
rpm -q --requires sendmail
</para>
<para>
You can use the -R short option in place of the --requires
option.
</para>
<para>
This command returns the same data as the previous command but
queries an installed package rather than an RPM package file.
</para>
<para>
You might assume that applications have the most dependencies,
which is true. But even source packages may depend on other
packages, often the packages needed to build the sources into an
application. For example, the following command lists the
capabilities required by a source RPM:
</para>
<para>
$ rpm -qp --requires telnet-0.17-23.src.rpm
</para>
<para>
ncurses-devel
</para>
<para>
Some packages require particular versions of other packages, for
example:
</para>
<para>
rpm -qp --requires xcdroast-0.98a9-18.src.rpm
</para>
<para>
imlib-devel >= 1.9.13-9
</para>
<para>
gtk+-devel >= 1.2.10
</para>
<para>
desktop-file-utils >= 0.2.92
</para>
<para>
rpmlib(CompressedFileNames) <= 3.0.4-1
</para>
<para>
This example shows that the xcdroast source package requires the
imlib-devel capability (in this case, a package) at version
1.9.13-9 or higher, the gtk+-devel package at version 1.2.10 or
higher, and the desktop-file-utils package at version 0.2.92 or
higher. This is a more stringent requirement than just depending
on the given packages being installed. This RPM is also an older
RPM package, based on the requirement for the rpmlib to be prior
or equal to 3.0.4-1.
</para>
<para>
Some packages may require a particular version of the rpmlib, or
RPM library. For example, the setup package contains special
system configuration files, including the default password file,
/etc/passwd.
</para>
<para>
$ rpm -q --requires setup
</para>
<para>
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
</para>
<para>
rpmlib(CompressedFileNames) <= 3.0.4-1
</para>
<para>
As shown in this example, this package depends only on
capabilities of the RPM system itself. The particular
requirements shown here specify how the rpm command should treat
the package payload, including how the files are listed in the
package and what type of compression is used.
</para>
</sect2>
<sect2>
<title>Determining the capabilities a package provides</title>
<para>
Packages require capabilities, and they can provide capabilities
for other packages to require. To list the capabilities a
package provides, use the --provides option. These capabilities
can be arbitrary names, shared libraries (.so files), and the
package name itself. The basic syntax is:
</para>
<para>
rpm ���q query_options --provides packages
</para>
<para>
For example, the tcsh shell package provides two capabilities,
at a particular version number, as shown following:
</para>
<para>
$ rpm -q --provides tcsh
</para>
<para>
csh = 6.12
</para>
<para>
tcsh = 6.12-2
</para>
<para>
Other packages provide a lot more, including shared libraries.
The httpd package provides a long list of capabilities, as shown
following:
</para>
<para>
$ rpm -q --provides httpd
</para>
<para>
webserver
</para>
<para>
httpd-mmn = 20020628
</para>
<para>
libapr.so.0
</para>
<para>
libaprutil.so.0
</para>
<para>
mod_access.so
</para>
<para>
mod_actions.so
</para>
<para>
mod_alias.so
</para>
<para>
mod_asis.so
</para>
<para>
mod_auth_anon.so
</para>
<para>
mod_auth_dbm.so
</para>
<para>
mod_auth_digest.so
</para>
<para>
mod_auth.so
</para>
<para>
mod_autoindex.so
</para>
<para>
mod_cern_meta.so
</para>
<para>
mod_cgi.so
</para>
<para>
mod_dav_fs.so
</para>
<para>
mod_dav.so
</para>
<para>
mod_deflate.so
</para>
<para>
mod_dir.so
</para>
<para>
mod_env.so
</para>
<para>
mod_expires.so
</para>
<para>
mod_headers.so
</para>
<para>
mod_imap.so
</para>
<para>
mod_include.so
</para>
<para>
mod_info.so
</para>
<para>
mod_log_config.so
</para>
<para>
mod_mime_magic.so
</para>
<para>
mod_mime.so
</para>
<para>
mod_negotiation.so
</para>
<para>
mod_proxy_connect.so
</para>
<para>
mod_proxy_ftp.so
</para>
<para>
mod_proxy_http.so
</para>
<para>
mod_proxy.so
</para>
<para>
mod_rewrite.so
</para>
<para>
mod_setenvif.so
</para>
<para>
mod_speling.so
</para>
<para>
mod_status.so
</para>
<para>
mod_suexec.so
</para>
<para>
mod_unique_id.so
</para>
<para>
mod_userdir.so
</para>
<para>
mod_usertrack.so
</para>
<para>
mod_vhost_alias.so
</para>
<para>
httpd = 2.0.40-8
</para>
</sect2>
<sect2>
<title>Checking for conflicts</title>
<para>
Use the --conflicts option to check what conflicts with a given
package. The basic syntax is:
</para>
<para>
rpm ���q query_options --conflicts packages
</para>
<para>
For example:
</para>
<para>
# rpm -q --conflicts httpd
</para>
<para>
thttpd
</para>
<para>
This command tells you that the httpd package (the Apache Web
server) conflicts with the thttpd package. Both packages provide
a similar capability. By marking the conflict, the httpd package
tells you that you cannot normally install both the httpd and
thttpd packages on a system. This information comes from the
httpd package, which has an entry in the package that indicates
the conflict. The conflict is not guaranteed. These packages may
work together, but the creator of the httpd package felt that
httpd would not work with the thttpd package and helpfully let
us all know.
</para>
<para>
The RPM system will report on the conflicts and indicate an
error if you try to install conflicting packages. The idea of
conflicts really gives package creators a way to alert users to
potential problems and to tell us that one package likely
won���t work with another.
</para>
<para>
The force options discussed in Chapter 4 allow you to override
conflicts, if absolutely necessary. In most cases, though, a
conflict presents you with the choice to install one or the
other of the packages, but not both.
</para>
</sect2>
<sect2>
<title>Determining which packages require a certain capability</title>
<para>
In addition to querying capabilities and requirements of a
particular package, you can query the capabilities themselves.
This function allows you to check which packages require a given
capability.
</para>
<para>
The --whatrequires option tells the rpm command to report on
which packages in the RPM database require a certain capability.
The basic syntax is:
</para>
<para>
rpm ���q query_options --whatrequires capability
</para>
<para>
Some packages are not required by anything:
</para>
<para>
$ rpm -q --whatrequires tcsh
</para>
<para>
no package requires tcsh
</para>
<para>
Note
</para>
<para>
Don���t worry about the poor tcsh package being lonely. Because
other packages do not require this package, you can easily
remove the tcsh package without affecting the rest of your
system.
</para>
<para>
This example shows a package name as the capability. Shared
libraries are also considered capabilities. You can query on
these as well. For example:
</para>
<para>
$ rpm -q --whatrequires librpm-4.1.so
</para>
<para>
rpm-4.1-1.06
</para>
<para>
net-snmp-5.0.1-6
</para>
<para>
rpm-python-4.1-1.06
</para>
<para>
rpm-devel-4.1-1.06
</para>
<para>
rpm-build-4.1-1.06
</para>
<para>
This example shows that the core RPM library is used by a number
of RPM-related packages, along with, oddly enough, the net-snmp
system-management package.
</para>
<para>
The capability you query for must be an explicit capability. For
example, you will get different results if you query for the
bash package or the command, /bin/bash. If you query for the
bash package, you will see the packages that explicitly require
the capability bash. For example:
</para>
<para>
$ rpm -q --whatrequires bash
</para>
<para>
gpm-1.19.3-20
</para>
<para>
info-4.0b-3
</para>
<para>
initscripts-6.40-1
</para>
<para>
sendmail-8.11.6-3
</para>
<para>
sysklogd-1.4.1-4
</para>
<para>
vixie-cron-3.0.1-63
</para>
<para>
ypbind-1.8-1
</para>
<para>
ypserv-1.3.12-2
</para>
<para>
If you instead query for the capability /bin/bash, that is, the
file /bin/bash, you will see a different list of packages. For
example:
</para>
<para>
$ rpm -q --whatrequires /bin/bash
</para>
<para>
apmd-3.0final-34
</para>
<para>
at-3.1.8-20
</para>
<para>
autofs-3.1.7-21
</para>
<para>
autofs-3.1.7-21
</para>
<para>
bash-2.05-8
</para>
<para>
bind-9.1.3-4
</para>
<para>
cipe-1.4.5-6
</para>
<para>
crontabs-1.10-1
</para>
<para>
dialog-0.9a-5
</para>
<para>
gpm-1.19.3-20
</para>
<para>
hotplug-2001_04_24-11
</para>
<para>
initscripts-6.40-1
</para>
<para>
ipchains-1.3.10-10
</para>
<para>
iproute-2.2.4-14
</para>
<para>
kudzu-0.99.23-1
</para>
<para>
logwatch-2.1.1-3
</para>
<para>
man-1.5i2-6
</para>
<para>
mkbootdisk-1.4.2-3
</para>
<para>
mkinitrd-3.2.6-1
</para>
<para>
mutt-1.2.5i-17
</para>
<para>
openssh-server-3.1p1-2
</para>
<para>
pine-4.44-1.72.0
</para>
<para>
rpm-build-4.0.3-1.03
</para>
<para>
rusers-server-0.17-12
</para>
<para>
sendmail-8.11.6-3
</para>
<para>
shapecfg-2.2.12-7
</para>
<para>
sharutils-4.2.1-8
</para>
<para>
sysklogd-1.4.1-4
</para>
<para>
tetex-1.0.7-30
</para>
<para>
ucd-snmp-4.2.1-7
</para>
<para>
vixie-cron-3.0.1-63
</para>
<para>
xinetd-2.3.3-1
</para>
<para>
ypbind-1.8-1
</para>
<para>
ypserv-1.3.12-2
</para>
<para>
There is no short form for the --whatrequires option.
</para>
<para>
Other capabilities, especially system-level shared libraries,
are used by a large number of packages. For example:
</para>
<para>
# rpm -q --whatrequires libcrypt.so.1 | sort
</para>
<para>
autofs-3.1.7-21
</para>
<para>
cvs-1.11.1p1-3
</para>
<para>
cyrus-sasl-1.5.24-23
</para>
<para>
cyrus-sasl-devel-1.5.24-23
</para>
<para>
cyrus-sasl-plain-1.5.24-23
</para>
<para>
fetchmail-5.9.0-1
</para>
<para>
ircii-4.4Z-7
</para>
<para>
krbafs-1.0.9-2
</para>
<para>
nss_ldap-172-2
</para>
<para>
openldap12-1.2.12-4
</para>
<para>
openldap-2.0.11-13
</para>
<para>
openldap-clients-2.0.11-13
</para>
<para>
pam-0.75-19
</para>
<para>
pam_krb5-1.46-1
</para>
<para>
passwd-0.64.1-7
</para>
<para>
perl-5.6.0-17
</para>
<para>
pine-4.44-1.72.0
</para>
<para>
pwdb-0.61.1-3
</para>
<para>
python-1.5.2-35
</para>
<para>
rsh-0.17-5
</para>
<para>
rsh-server-0.17-5
</para>
<para>
screen-3.9.9-3
</para>
<para>
sendmail-8.11.6-3
</para>
<para>
shadow-utils-20000902-4
</para>
<para>
sh-utils-2.0.11-5
</para>
<para>
SysVinit-2.78-19
</para>
<para>
tcsh-6.10-6
</para>
<para>
util-linux-2.11f-17
</para>
<para>
vim-enhanced-5.8-7
</para>
<para>
wu-ftpd-2.6.1-20
</para>
<para>
xinetd-2.3.3-1
</para>
<para>
ypserv-1.3.12-2
</para>
<para>
yp-tools-2.5-1
</para>
<para>
Quite a few packages require encryption and decryption (the
purpose of this library), making this library crucial to
operating the system. Many of the packages listed here are in
turn depended on by even more packages.
</para>
<para>
To help trace back capabilities, you can combine the queries.
For example:
</para>
<para>
$ rpm -q --provides sendmail
</para>
<para>
smtpdaemon
</para>
<para>
sendmail = 8.11.6-3
</para>
<para>
$ rpm -q --whatrequires smtpdaemon
</para>
<para>
fetchmail-5.9.0-1
</para>
<para>
mutt-1.2.5i-17
</para>
<para>
The first command lists the capabilities that the sendmail
package provides, including the generic capability of
smtpdaemon. You can then list which packages require this
particular capability, as shown in the second command. This is a
big help for wading through a mess of packages depending on
packages depending on yet more packages.
</para>
</sect2>
<sect2>
<title>Determining which package provides a certain capability</title>
<para>
To complete the circle, you can query for which package provides
a certain capability. This knowledge allows you to trace a
requirement back to the package that provides it.
</para>
<para>
The --whatprovides option tells the rpm command to list the
capabilities a package provides. Use the --whatprovides option
with the ���q, or query, option to the rpm command. (There is no
short form for the --whatrprovides option.)
</para>
<para>
The basic syntax follows:
</para>
<para>
rpm ���q --whatprovides capability
</para>
<para>
For example, to query what package provides the capability
webserver, use the following command:
</para>
<para>
$ rpm -q --whatprovides webserver
</para>
<para>
httpd-2.0.40-8
</para>
<para>
In this case, the capability is identified by an arbitrary
string, webserver. This is a generic name for a given
capability, serving Web pages.
</para>
<para>
You can also trace individual files using the --whatprovides
option. For example:
</para>
<para>
$ rpm -q --whatprovides /etc/skel/.bashrc
</para>
<para>
bash-2.05-8
</para>
<para>
Note
</para>
<para>
The rpm ���qf command, covered in the last chapter, is an easier
way to get to the same information when tracking which package
provides a particular file. For example:
</para>
<para>
rpm -qf /etc/skel/.bashrc
</para>
<para>
bash-2.05-8
</para>
<para>
If you are querying particular files, use rpm ���qf. If you are
querying capabilities, use --whatprovides.
</para>
</sect2>
</sect1>
<sect1>
<title>Triggers</title>
<para>
A trigger is a script that gets run when a package is installed or
uninstalled. Triggers allow packages that depend on other packages
to properly configure themselves when those other packages are
installed or removed.
</para>
<para>
The --triggers option to the rpm command lists any trigger scripts
in a given package. For example:
</para>
<para>
$ rpm -q --triggers sendmail
</para>
<para>
triggerpostun script (through /bin/sh) -- sendmail < 8.10.0
</para>
<para>
/sbin/chkconfig --add sendmail
</para>
<para>
This shows that the sendmail mail transfer agent (mail-sending
program) provides a short trigger script.
</para>
<para>
In contrast, the anonftp (anonymous file transfer) package has a
fairly complex set of triggers, as shown following:
</para>
<para>
$ rpm -q --triggers anonftp
</para>
<para>
triggerin script (through /bin/sh) -- glibc
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
# Kill off old versions
</para>
<para>
rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl*
/var/ftp/lib/lib
</para>
<para>
nss_files* &>/dev/null || :
</para>
<para>
# Copy parts of glibc, needed by various programs in bin.
</para>
<para>
LIBCVER=`basename $(ls --sort=time /lib/libc-*.so |head -n 1) .so
|cut -f2- -d-`
</para>
<para>
copy /lib/ld-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libc-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib
</para>
<para>
md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.*
2>/dev/null >/var
</para>
<para>
/ftp/lib/libs.md5
</para>
<para>
chmod 0400 /var/ftp/lib/libs.md5
</para>
<para>
# Use ldconfig to build symlinks and whatnot.
</para>
<para>
[ ! -e /var/ftp/etc/ld.so.conf ] && touch
/var/ftp/etc/ld.so.conf
</para>
<para>
/sbin/ldconfig -r /var/ftp
</para>
<para>
triggerin script (through /bin/sh) -- fileutils
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
copy /bin/ls /var/ftp/bin
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
triggerin script (through /bin/sh) -- cpio
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
copy /bin/cpio /var/ftp/bin
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
triggerin script (through /bin/sh) -- tar
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
copy /bin/tar /var/ftp/bin
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
triggerin script (through /bin/sh) -- gzip
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
copy /bin/gzip /var/ftp/bin
</para>
<para>
ln -sf gzip /var/ftp/bin/zcat
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
triggerin script (through /bin/sh) -- libtermcap
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :
</para>
<para>
copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib
</para>
<para>
md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.*
2>/dev/null >/var
</para>
<para>
/ftp/lib/libs.md5
</para>
<para>
chmod 0400 /var/ftp/lib/libs.md5
</para>
<para>
# Use ldconfig to build symlinks and whatnot.
</para>
<para>
[ ! -e /var/ftp/etc/ld.so.conf ] && touch
/var/ftp/etc/ld.so.conf
</para>
<para>
/sbin/ldconfig -r /var/ftp
</para>
<para>
triggerin script (through /bin/sh) -- ncompress
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
copy /usr/bin/compress /var/ftp/bin
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
triggerpostun script (through /bin/sh) -- anonftp 4.0
</para>
<para>
if [ "$2" != 1 ] ; then
</para>
<para>
# The user has multiple glibc packages installed. We can't read
the
</para>
<para>
# user's mind, so don't do anything.
</para>
<para>
exit 0
</para>
<para>
fi
</para>
<para>
copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2"
2>/dev/null |
</para>
<para>
| cp -df "$file" "$2"; }
</para>
<para>
# Kill off old versions
</para>
<para>
rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl*
/var/ftp/lib/lib
</para>
<para>
nss_files* &>/dev/null || :
</para>
<para>
# Copy parts of glibc, needed by various programs in bin.
</para>
<para>
LIBCVER=`basename /lib/libc-*.so .so | cut -f2- -d-`
</para>
<para>
copy /lib/ld-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libc-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib
</para>
<para>
copy /bin/ls /var/ftp/bin
</para>
<para>
copy /bin/cpio /var/ftp/bin
</para>
<para>
copy /bin/tar /var/ftp/bin
</para>
<para>
copy /bin/gzip /var/ftp/bin
</para>
<para>
ln -sf gzip /var/ftp/bin/zcat
</para>
<para>
copy /usr/bin/compress /var/ftp/bin
</para>
<para>
rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :
</para>
<para>
copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib
</para>
<para>
# Use ldconfig to build symlinks and whatnot.
</para>
<para>
[ ! -e /var/ftp/etc/ld.so.conf ] && touch
/var/ftp/etc/ld.so.conf
</para>
<para>
/sbin/ldconfig -r /var/ftp
</para>
<para>
# Generate md5sums for verifyscript
</para>
<para>
md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.*
2>/dev/null >/var
</para>
<para>
/ftp/lib/libs.md5
</para>
<para>
chmod 0400 /var/ftp/lib/libs.md5
</para>
<para>
md5sum `ls /var/ftp/bin/* |grep -v bin.md5`
>/var/ftp/bin/bin.md5
</para>
<para>
chmod 0400 /var/ftp/bin/bin.md5
</para>
<para>
Reading through the scripts indicates that this package seems to
be triggered by the glibc standard C programming library package.
You can confirm this by using the --triggeredby option to the rpm
command, as shown following:
</para>
<para>
$ rpm -q --triggeredby glibc
</para>
<para>
anonftp-4.0-9
</para>
<para>
The anonftp package needs to be notified on changes to the glibc
package, so that the anonftp package can properly set up its
application. It actually uses part of glibc and is therefore
highly susceptible to changes in the glibc package. Thus, the use
of triggers provides essentially an extended form of dependencies.
The anonftp package in this example depends so much on the glibc
package that it needs to execute scripts whenever the glibc
package changes.
</para>
</sect1>
<sect1>
<title>Summary</title>
<para>
Linux comes with many packages. Most of these packages depend on
some other packages installed on your system. In RPM terms,
packages provide capabilities and depend on capabilities that
other packages provide. When the rpm command checks the RPM
database for dependencies, it checks to ensure that all the
capabilities that a given package requires are met by other
installed packages.
</para>
<para>
You can trace the capabilities a package requires with the
--requires option to the rpm command. You can see what
capabilities a package provides for others with the --provides
option.
</para>
<para>
Once you know a capability, you can query which package provides
that capability with the --whatprovides option to the rpm command.
And you can see which packages require that capability with the
--whatrequires option.
</para>
<para>
Triggers are an extended form of dependencies. A trigger is a
script that gets executed when other packages are installed or
removed. This allows a package with a high dependence on another
package to track changes in that package and reconfigure itself as
needed.
</para>
<para>
The next chapter delves into transactions, which provide a safe
means to install a set of packages. With transactions, either all
the packages get installed, or none.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
18 years, 6 months