rpm-guide rpm-guide-dependencies-en.xml,NONE,1.1
Stuart Ellis (elliss)
fedora-docs-commits at redhat.com
Tue Oct 4 01:49:43 UTC 2005
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:
-->
More information about the Fedora-docs-commits
mailing list