<ctrl-d>

libc.so.5

#

Okay, so /lib/libc.so.5.3.12's soname is libc.so.5. Let's see if the libc package really does provide the libc.so.5 soname:

# rpm -q --provides libc

libm.so.5

libc.so.5

#

Yes, there it is, along with the soname of another library contained in the package. In this way, RPM can ensure that any package requiring libc.so.5 will have a compatible library available as long as the libc package, which provides libc.so.5, is installed.

In most cases, automatic dependencies are enough to fill the bill. However, there are circumstances when the package builder has to manually add dependency information to a package. Fortunately, RPM's approach to manual dependencies is both simple and flexible.

14.2.3. The autoreqprov Tag: Disable Automatic Dependency Processing

There may be times when RPM's automatic dependency processing is not desired. In these cases, the autoreqprov tag may be used to disable it. This tag takes a yes/no or 0/1 value. For example, to disable automatic dependency processing, the following line may be used:

AutoReqProv: no

14.3. Manual Dependencies

You might have noticed that we've been using the words requires and provides to describe the dependency relationships between packages. As it turns out, these are the exact words used in spec files to manually add dependency information. Let's look at the first tag: requires.

14.3.1. The requires Tag

We've been deliberately vague when discussing exactly what it is that a package requires. Although we've used the word capabilities, in fact, manual dependency requirements are always represented in terms of packages. For example, if package foo requires that package bar is installed, it's only necessary to add the following line to foo's spec file:

requires: bar

Later, when the foo package is being installed, RPM will consider foo's dependency requirements met if any version of package bar is already installed. As long as the requiring and the

providing packages are installed using the same invocation of RPM, the dependency checking will succeed. For example, the command rpm -ivh *.rpm will properly check for dependencies, even if the requiring package ends up being installed before the providing package.

If more than one package is required, they can be added to the requires tag, one after another, separated by commas and/or spaces. So if package foo requires packages bar and baz, the following line will do the trick:

requires: bar, baz

As long as any version of bar and baz is installed, foo's dependencies will be met.

When a package has slightly more stringent needs, it's possible to require certain versions of a package. All that's necessary is to add the desired version number, preceded by one of the following comparison operators:

<	Requires a package with a version less than the specified version.
<=	Requires a package with a version less than or equal to the specified version.
=	Requires a package with a version equal to the specified version.
>=	Requires a package with a version greater than or equal to the specified version.
>	Requires a package with a version greater than the specified version.

Continuing with our example, let's suppose that the required version of package bar actually needs to be at least 2.7, and that the baz package must be version 2.1—no other version will do. Here's what the requires tag line would look like:

requires: bar >= 2.7, baz = 2.1

We can get even more specific and require a particular release of a package:

requires: bar >= 2.7-4, baz = 2.1-1

You might think that with all these features, RPM's dependency processing can handle every conceivable situation. You'd be right, except for the problem of version numbers. RPM needs to be able to determine which version numbers are more recent than others in order to perform its version comparisons.

It's pretty simple to determine that version 1.5 is older than version 1.6. But what about 2.01 and 2.1? Or 7.6a and 7.6? There's no way for RPM to keep up with all the different version-numbering schemes in use. But there is a solution; there are two, in fact.

When RPM can't decipher a package's version number, it's time to pull out the serial tag. This tag is used to help RPM determine version number ordering. Here's a sample serial tag line:

Serial: 42

This line indicates that the package has the serial number 42. What does the 42 mean? Only that this version of the package is older than the same package with the serial number 41, but younger than the same package with the serial number 43. If you think of serial numbers as being nothing more than very simple version numbers, you'll be on the mark.

In order to direct RPM to look at the serial number instead of the version number when doing dependency checking, it's necessary to append an S to the end of the conditional operator in the requires tag line. So if a package requires package foo to have a serial number equal to 42, the following tag line would be used:

Requires: foo =S 42

If the foo package needs to have a serial number greater than or equal to 42, this line would work:

Requires: foo >=S 42

It might seem that using serial numbers is a lot of extra trouble, and you're right. But there is an alternative.

If you have the option between changing the software's version-numbering scheme or using serial numbers in RPM, consider changing the version-numbering scheme. Chances are, if RPM can't figure it out, most of the people using your software can't, either. But in case you aren't the author of the software you're packaging, and its version numbering scheme is giving RPM fits, the serial tag can help you out.

14.3.2. The conflicts Tag

The conflicts tag is the logical complement to the requires tag. It is used to specify which packages conflict with the current package. RPM will not permit conflicting packages to be installed unless overridden with the --nodeps option.

The conflicts tag has the same format as requires. It accepts a real or virtual package name and can optionally include version and release specifications or a serial number.