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.
5.1. 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.
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
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 3, Using RPM 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.
5.1.2. 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.
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 3, Using RPM , and override the RPM system. But in most cases, you should not install packages that conflict.
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.
