Chapter 06

Package Dependencies

In This Chapter

*	Understanding dependencies

*	Package capabilities

*	Version dependencies

*	Checking dependencies

*	Triggers

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.

This chapter covers dependencies between packages, along with ways to discover and manage those dependencies.

Understanding the Dependency Concept

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.

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.

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.

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.

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.

Capabilities

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.

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.

Cross Reference

Package dependencies and capabilities are very important when creating spec files for building your own RPM packages, the subject of Chapter 10.

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:

# rpm -e setup

error: Failed dependencies:

setup is needed by (installed) basesystem-8.0-1

setup >= 2.0.3 is needed by (installed) initscripts-6.95-1

setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5

setup is needed by (installed) xinetd-2.3.7-2

setup is needed by (installed) dump-0.4b28-4

To verify that the package has not been removed, you can query for the package after trying to remove it, as shown following:

# rpm -q setup

setup-2.5.20-1

This shows that the rpm command has not removed the setup package due to the errors.

Cross Reference

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.

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.

Note

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.

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.

Note

To list the shared libraries that a program accesses, use the ldd command, for example:

$ ldd /bin/grep

libc.so.6 => /lib/i686/libc.so.6 (0x42000000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Other dependencies include version-specific dependencies.

Version dependencies

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.

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

Note

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.

Conflicts

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.

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.

Obsoletes

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.

This brings the total to four types of dependencies that the RPM system tracks:

*	Requires, which tracks the capabilities a package requires

*	Provides, which tracks the capabilities a package provides for other packages

*	Conflicts, which describes the capabilities that if installed, conflict with capabilities in a package

*	Obsoletes, which describes the capabilities that this package will make obsolete

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

You can check package dependencies by using, as you’d guess, the rpm command.

Checking for Dependencies

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.

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.

Cross Reference

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.

Determining the capabilities a package requires

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.

The --requires option to the rpm –q command lists the capabilities a given package requires. The basic syntax is:

rpm –q query_options --requires packages

For example:

$ rpm -qp --requires sendmail-8.12.5-7.i386.rpm

/usr/sbin/alternatives

rpmlib(VersionedDependencies) <= 3.0.3-1

chkconfig >= 1.3

/usr/sbin/useradd

/bin/mktemp

fileutils

gawk

sed

sh-utils

procmail

bash >= 2.0

/bin/sh

/bin/sh

/bin/sh

/bin/sh

/bin/sh

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

/bin/bash

libcrypto.so.2

libcrypt.so.1

libc.so.6

libc.so.6(GLIBC_2.0)

libc.so.6(GLIBC_2.1)

libc.so.6(GLIBC_2.1.3)

libc.so.6(GLIBC_2.2)

libdb-4.0.so

libgdbm.so.2

libhesiod.so.0

liblber.so.2

libldap.so.2

libnsl.so.1

libnsl.so.1(GLIBC_2.0)

libresolv.so.2

libresolv.so.2(GLIBC_2.0)

libresolv.so.2(GLIBC_2.2)

libsasl.so.7

libssl.so.2

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

Warning

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.

You can also check for what an installed package requires with the --requires option. For example:

rpm -q --requires sendmail

You can use the -R short option in place of the --requires option.

This command returns the same data as the previous command but queries an installed package rather than an RPM package file.

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:

$ rpm -qp --requires telnet-0.17-23.src.rpm

ncurses-devel

Some packages require particular versions of other packages, for example:

rpm -qp --requires xcdroast-0.98a9-18.src.rpm

imlib-devel >= 1.9.13-9

gtk+-devel >= 1.2.10

desktop-file-utils >= 0.2.92

rpmlib(CompressedFileNames) <= 3.0.4-1

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.

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.

$ rpm -q --requires setup

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

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.

Determining the capabilities a package provides

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:

rpm –q query_options --provides packages

For example, the tcsh shell package provides two capabilities, at a particular version number, as shown following:

$ rpm -q --provides tcsh

csh = 6.12

tcsh = 6.12-2

Other packages provide a lot more, including shared libraries. The httpd package provides a long list of capabilities, as shown following:

$ rpm -q --provides httpd

webserver

httpd-mmn = 20020628

libapr.so.0

libaprutil.so.0

mod_access.so

mod_actions.so

mod_alias.so

mod_asis.so

mod_auth_anon.so

mod_auth_dbm.so

mod_auth_digest.so

mod_auth.so

mod_autoindex.so

mod_cern_meta.so

mod_cgi.so

mod_dav_fs.so

mod_dav.so

mod_deflate.so

mod_dir.so

mod_env.so

mod_expires.so

mod_headers.so

mod_imap.so

mod_include.so

mod_info.so

mod_log_config.so

mod_mime_magic.so

mod_mime.so

mod_negotiation.so

mod_proxy_connect.so

mod_proxy_ftp.so

mod_proxy_http.so

mod_proxy.so

mod_rewrite.so

mod_setenvif.so

mod_speling.so

mod_status.so

mod_suexec.so

mod_unique_id.so

mod_userdir.so

mod_usertrack.so

mod_vhost_alias.so

httpd = 2.0.40-8

Checking for conflicts

Use the --conflicts option to check what conflicts with a given package. The basic syntax is:

rpm –q query_options --conflicts packages

For example:

# rpm -q --conflicts httpd

thttpd

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.

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.

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.

Determining which packages require a certain capability

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.

The --whatrequires option tells the rpm command to report on which packages in the RPM database require a certain capability. The basic syntax is:

rpm –q query_options --whatrequires capability

Some packages are not required by anything:

$ rpm -q --whatrequires tcsh

no package requires tcsh

Note

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.

This example shows a package name as the capability. Shared libraries are also considered capabilities. You can query on these as well. For example:

$ rpm -q --whatrequires librpm-4.1.so

rpm-4.1-1.06

net-snmp-5.0.1-6

rpm-python-4.1-1.06

rpm-devel-4.1-1.06

rpm-build-4.1-1.06

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.

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:

$ rpm -q --whatrequires bash

gpm-1.19.3-20

info-4.0b-3

initscripts-6.40-1

sendmail-8.11.6-3

sysklogd-1.4.1-4

vixie-cron-3.0.1-63

ypbind-1.8-1

ypserv-1.3.12-2

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:

$ rpm -q --whatrequires /bin/bash

apmd-3.0final-34

at-3.1.8-20

autofs-3.1.7-21

autofs-3.1.7-21

bash-2.05-8

bind-9.1.3-4

cipe-1.4.5-6

crontabs-1.10-1

dialog-0.9a-5

gpm-1.19.3-20

hotplug-2001_04_24-11

initscripts-6.40-1

ipchains-1.3.10-10

iproute-2.2.4-14

kudzu-0.99.23-1

logwatch-2.1.1-3

man-1.5i2-6

mkbootdisk-1.4.2-3

mkinitrd-3.2.6-1

mutt-1.2.5i-17

openssh-server-3.1p1-2

pine-4.44-1.72.0

rpm-build-4.0.3-1.03

rusers-server-0.17-12

sendmail-8.11.6-3

shapecfg-2.2.12-7

sharutils-4.2.1-8

sysklogd-1.4.1-4

tetex-1.0.7-30

ucd-snmp-4.2.1-7

vixie-cron-3.0.1-63

xinetd-2.3.3-1

ypbind-1.8-1

ypserv-1.3.12-2

There is no short form for the --whatrequires option.

Other capabilities, especially system-level shared libraries, are used by a large number of packages. For example:

# rpm -q --whatrequires libcrypt.so.1 | sort

autofs-3.1.7-21

cvs-1.11.1p1-3

cyrus-sasl-1.5.24-23

cyrus-sasl-devel-1.5.24-23

cyrus-sasl-plain-1.5.24-23

fetchmail-5.9.0-1

ircii-4.4Z-7

krbafs-1.0.9-2

nss_ldap-172-2

openldap12-1.2.12-4

openldap-2.0.11-13

openldap-clients-2.0.11-13

pam-0.75-19

pam_krb5-1.46-1

passwd-0.64.1-7

perl-5.6.0-17

pine-4.44-1.72.0

pwdb-0.61.1-3

python-1.5.2-35

rsh-0.17-5

rsh-server-0.17-5

screen-3.9.9-3

sendmail-8.11.6-3

shadow-utils-20000902-4

sh-utils-2.0.11-5

SysVinit-2.78-19

tcsh-6.10-6

util-linux-2.11f-17

vim-enhanced-5.8-7

wu-ftpd-2.6.1-20

xinetd-2.3.3-1

ypserv-1.3.12-2

yp-tools-2.5-1

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.

To help trace back capabilities, you can combine the queries. For example:

$ rpm -q --provides sendmail

smtpdaemon

sendmail = 8.11.6-3

$ rpm -q --whatrequires smtpdaemon

fetchmail-5.9.0-1

mutt-1.2.5i-17

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.

Determining which package provides a certain capability

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.

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

The basic syntax follows:

rpm –q --whatprovides capability

For example, to query what package provides the capability webserver, use the following command:

$ rpm -q --whatprovides webserver

httpd-2.0.40-8

In this case, the capability is identified by an arbitrary string, webserver. This is a generic name for a given capability, serving Web pages.

You can also trace individual files using the --whatprovides option. For example:

$ rpm -q --whatprovides /etc/skel/.bashrc

bash-2.05-8

Note

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:

rpm -qf /etc/skel/.bashrc

bash-2.05-8

If you are querying particular files, use rpm –qf. If you are querying capabilities, use --whatprovides.

Triggers

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.

The --triggers option to the rpm command lists any trigger scripts in a given package. For example:

$ rpm -q --triggers sendmail

triggerpostun script (through /bin/sh) -- sendmail < 8.10.0

/sbin/chkconfig --add sendmail

This shows that the sendmail mail transfer agent (mail-sending program) provides a short trigger script.

In contrast, the anonftp (anonymous file transfer) package has a fairly complex set of triggers, as shown following:

$ rpm -q --triggers anonftp

triggerin script (through /bin/sh) -- glibc

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

# Kill off old versions

rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib

nss_files* &>/dev/null || :

# Copy parts of glibc, needed by various programs in bin.

LIBCVER=`basename $(ls --sort=time /lib/libc-*.so |head -n 1) .so |cut -f2- -d-`

copy /lib/ld-${LIBCVER}.so /var/ftp/lib

copy /lib/libc-${LIBCVER}.so /var/ftp/lib

copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib

copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib

md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var

/ftp/lib/libs.md5

chmod 0400 /var/ftp/lib/libs.md5

# Use ldconfig to build symlinks and whatnot.

[ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf

/sbin/ldconfig -r /var/ftp

triggerin script (through /bin/sh) -- fileutils

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

copy /bin/ls /var/ftp/bin

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

triggerin script (through /bin/sh) -- cpio

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

copy /bin/cpio /var/ftp/bin

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

triggerin script (through /bin/sh) -- tar

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

copy /bin/tar /var/ftp/bin

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

triggerin script (through /bin/sh) -- gzip

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

copy /bin/gzip /var/ftp/bin

ln -sf gzip /var/ftp/bin/zcat

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

triggerin script (through /bin/sh) -- libtermcap

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :

copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib

md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var

/ftp/lib/libs.md5

chmod 0400 /var/ftp/lib/libs.md5

# Use ldconfig to build symlinks and whatnot.

[ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf

/sbin/ldconfig -r /var/ftp

triggerin script (through /bin/sh) -- ncompress

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

copy /usr/bin/compress /var/ftp/bin

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

triggerpostun script (through /bin/sh) -- anonftp 4.0

if [ "$2" != 1 ] ; then

# The user has multiple glibc packages installed. We can't read the

# user's mind, so don't do anything.

exit 0

fi

copy() { file="`ls --sort=time $1 |head -n 1`"; ln -f "$file" "$2" 2>/dev/null |

| cp -df "$file" "$2"; }

# Kill off old versions

rm -f /var/ftp/lib/ld-* /var/ftp/lib/libc* /var/ftp/lib/libnsl* /var/ftp/lib/lib

nss_files* &>/dev/null || :

# Copy parts of glibc, needed by various programs in bin.

LIBCVER=`basename /lib/libc-*.so .so | cut -f2- -d-`

copy /lib/ld-${LIBCVER}.so /var/ftp/lib

copy /lib/libc-${LIBCVER}.so /var/ftp/lib

copy /lib/libnsl-${LIBCVER}.so /var/ftp/lib

copy /lib/libnss_files-${LIBCVER}.so /var/ftp/lib

copy /bin/ls /var/ftp/bin

copy /bin/cpio /var/ftp/bin

copy /bin/tar /var/ftp/bin

copy /bin/gzip /var/ftp/bin

ln -sf gzip /var/ftp/bin/zcat

copy /usr/bin/compress /var/ftp/bin

rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :

copy '/lib/libtermcap.so.*.*.*' /var/ftp/lib

# Use ldconfig to build symlinks and whatnot.

[ ! -e /var/ftp/etc/ld.so.conf ] && touch /var/ftp/etc/ld.so.conf

/sbin/ldconfig -r /var/ftp

# Generate md5sums for verifyscript

md5sum /var/ftp/lib/lib*-*.so /var/ftp/lib/libtermcap.so.*.*.* 2>/dev/null >/var

/ftp/lib/libs.md5

chmod 0400 /var/ftp/lib/libs.md5

md5sum `ls /var/ftp/bin/* |grep -v bin.md5` >/var/ftp/bin/bin.md5

chmod 0400 /var/ftp/bin/bin.md5

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:

$ rpm -q --triggeredby glibc

anonftp-4.0-9

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.

Summary

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.

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.

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.

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.

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.

Chapter 06

Chris Ricker

2003-01-15T15:35:00

Eric Foster-Johnson