DEPENDENCIES
============

Dependencies provide a way for a package builder to require other
packages or capabilities to be installed before or simultaneously
with one another. These can be used to require a python interpretor
for a python based application for example. RPM ensures dependencies
are satisfied whenever packages are installed, erased, or upgraded.

Requiring Packages
------------------

To require packages, use:

	Requires: python perl

in the spec file. Note that "Requires python, perl" would work as well. If you
needed to have a very recent version of python but any version of perl,

	Requires: python >= 1.3, perl

would do the trick. Again, the ',' in the line is optional.  Instead of
'>=', you may also use '<', '>', '<=', or '='.

RPM uses an internal algorithm to determine version number orderings which
works correctly most of the time. For example, it will know that
1.9a is older then 1.9b. However, it will also be later then 1.9 which
may or may not be correct as some programmers use letters in version numbers
to indicate beta versions. 

To work around this, you may specify an epoch number for a package like this:

	Epoch: 23

If a Requires: line needs to include an epoch in the comparison, then
the line should be written like

	Requires: somepackage = 23:version

You can't continue a "Requires: " line. If you have multiple
"Requires: " lines then the package requires all packages mentioned on
all of the lines to be installed. Max line length is probably 8K.

The full syntax for specifying a dependency on an epoch, version and release
is
	[epoch:]version[-release]
where
	epoch	(optional) number, with assumed default of 0 if not supplied
	version	(required) can contain any character except '-'
	release	(optional) can contain any character except '-'

Prereqs
-------

Prereqs are slightly different than requires. If multiple packages are
given on a single command line, then RPM will rearrange the package
order to ensure that the installation order obeys the requirements. A
package's prereqs are guaranteed to be installed on the machine before
the package itself is installed. Otherwise prereqs are identical to
requires.


Virtual Packages
----------------

Sometimes you need to make sure the system your package is being installed 
on has a package which provides a certain capability, even though you don't
care what specific package provides it. For example, sendmail won't work
properly unless a local delivery agent (lda) is present. You can ensure that
one is installed like this:

	Requires: lda

This will match either a package called lda (as mentioned above), or any
package which contains:

	Provides: lda

in its .spec file. No version numbers may be used with virtual packages.

Virtual packages are often used to supply file dependencies such as /bin/sh
on machines that are only partly managed by rpm. A virtual package with
	Provides: /bin/sh
differs from a package that has /bin/sh in the %files list in that the
package can be safely removed without removing /bin/sh.

Automatic Dependencies
----------------------

To reduce the amount of work required by the package builder, RPM scans
the file list of a package when it is being built. Any files in the file
list which require shared libraries to work (as determined by ldd) cause
that package to require the shared library.

For example, if your package contains /bin/vi, RPM will add dependencies 
for both libtermcap.so.2 and libc.so.5. These are treated as virtual
packages, so no version numbers are used.

A similar process allows RPM to add Provides information automatically. Any
shared library in the file list is examined for its soname (the part of
the name which must match for two shared libraries to be considered
equivalent) and that soname is automatically provided by the package. For
example, the libc-5.3.12 package has provides information added for
libm.so.5 and libc.so.5. We expect this automatic dependency generation
to eliminate the need for most packages to use explicit Requires: lines.


Interpreters and Shells (to be implemented)
-----------------------

Modules for interpreted languages like perl and tcl impose additional
dependency requirements on packages. A script written for an interpreter
often requires language specfic modules to be installed in order to execute
correctly. In order to automatically detect langiage specific modules, each
interpreter may have its own find-provides and find-requires. To prevent
module name collisions between interpreters, module names are enclosed within
parentheses and a conventional interpreter specific identifier is pre-pended:


  Provides: perl(MIME-Base64), perl(Mail-Header)-1-09

  Requires: perl(Carp), perl(IO-Wrap) = 4.5


The output of a per-interpreter find-requires (notice in this example the
first requirement is a package and the rest are langague specific modules)

	Mail-Header >= 1.01
	perl(Carp) >= 3.2
	perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5

the output from find-provides is
	Foo-0.9
	perl(Widget)-0-1

The per-interpreter automatic module detectors will normally be located in
	/usr/lib/rpm/{perl,tcl}/find-{provides,requires}
with appropriate per-interpreter hooks into
	/usr/lib/rpm/find-{provides,requires}

Notice that shell dependencies will require that all executable programs be
tracked by the dependency processing system. Since a shell script depends on
all the programs which it runs. In this way executables are much like shared
libraries for shell scripts.


Installing and Erasing Packages with Dependencies
-------------------------------------------------

For the most part, dependencies should be transparent to the user. However,
a few things will change.

First, when packages are added or upgraded, all of their dependencies
must be satisfied. If they are not, an error message like this appears:

    failed dependencies:
	    libICE.so.6  is needed by somepackage-2.11-1
	    libSM.so.6  is needed by somepackage-2.11-1
	    libc.so.5  is needed by somepackage-2.11-1

Similarly, when packages are removed, a check is made to ensure that 
no installed packages will have their dependency conditions break due to
the packages being removed. If you wish to turn off dependency checking for 
a particular command, use the --nodeps flag.

Conflicts
---------

While conflicts were implemented in earlier versions of RPM they never 
worked properly until RPM 2.3.4 (well, we hope they work properly now
anyway).

Conflicts allow a package to say it won't work with another package (or
virtual package) installed on the system. For example, qmail doesn't work
(w/o custom setup) on machines with sendmail installed. The qmail spec file
may codify this with a line like:

Conflicts: sendmail

The syntax of the "Conflicts" tag is identical to the syntax of the Requires
tag and conflict checking may be overridden by using the --nodeps flag.

Querying with Dependencies
--------------------------

Two new query information selection options are now available. The first, 
--provides, prints a list of all of the capabilities a package provides. 
The second, --requires, shows the other packages that a package requires
to be installed, along with any version number checking.

There are also two new ways to search for packages. Running a query with 
--whatrequires <item> queries all of the packages that require <item>. 
Similarly, running --whatprovides <item> queries all of the packages that 
provide the <item> virtual package. Note that querying for package that 
provides "python" will not return anything, as python is a package, not
a virtual package.

Verifying Dependencies
----------------------

As of RPM 2.2.2, -V (aka -y, --verify) verifies package dependencies
by default. You can tell rpm to ignore dependencies during system
verification with the --nodeps. If you want RPM to verify just dependencies
and not file attributes (including file existence), use the --nofiles
flag. Note that "rpm -Va --nofiles --nodeps" will not verify anything at
all, nor generate an error message.
