require the mail-reader virtual package. It would then install without dependency problems, if any one of several mail programs were installed. Here's what a provides tag might look like:

Provides: mail-reader

The requires tag is used to warn RPM that the package needs to have certain capabilities available in order to operate properly. These capabilities refer to the name of another package or to a virtual package provided by one or more packages that use the provides tag. When the requires tag references a package name, you can include version comparisons by following the package name with a version specification and <, >, =, >= or <=. To get even more specific, you can include a package's release as well. Here's a requires tag in action, with a specific version requirement:

Requires: playmidi = 2.3

If the requires tag needs to perform a comparison against a serial number defined with the serial tag, the following would be the proper format:

Requires: playmidi =S 4

The conflicts tag is the logical complement to the requires tag. The requires tag is used to specify what packages must be present in order for the current package to operate properly. The conflicts tag is used to specify what packages cannot be installed if the current package is to operate properly.

The conflicts tag has the same format as the requires tag—namely, the tag is followed by a real or virtual package name. Like requires, the conflicts tag also accepts version and release specifications:

Conflicts: playmidi = 2.3-1

If the conflicts tag needs to perform a comparison against a serial number defined with the serial tag, this would be the proper format:

Conflicts: playmidi =S 4

The serial tag is another part of RPM's dependency and upgrade processing. The need for it is somewhat obscure, but goes something like this:

• The package being built (call it package A) uses a version numbering scheme sufficiently obscure so that RPM cannot determine if one version is older or newer than another version.

• Another package (package B) requires that package A be installed. More specifically, it requires RPM to compare package A's version against a specified minimum (or maximum) version.

Because RPM is unable to compare package A's version against the version specified by package B, there is no way to determine if package B's dependency requirements can be met. What to do?

The serial tag provides a way to get around this tricky problem. By specifying a simple integer serial number for each version, you are, in essence, directing how RPM interprets the relative age of the package. The key point to keep in mind is that in order for this to work, a unique serial number must be defined for each version of the software being packaged. In addition, the serial number must increment along with the version. Finally, the package that requires the serialized software needs to specify its version requirements in terms of the serial number.

Does it sound like a lot of trouble? You're right! If you find yourself in the position of needing to use this tag, take a deep breath and seriously consider changing the way you assign version numbers. If you're packaging someone else's software, perhaps you can convince him to make the change. Chances are, if RPM can't figure out the version number, most people can't, either! An example of a serial tag would look something like this:

Serial: 4

Note that RPM considers a package with a serial number as newer than a package without a serial number.

The autoreqprov tag is used to control the automatic dependency processing performed when the package is being built. Normally, as each package is built, the following steps are performed:

• All executable programs being packaged are analyzed to determine their shared library requirements. These requirements are automatically added to the package's requirements.
• The soname (the name used to determine compatibility between different versions of a library) of each shared library being packaged is automatically added to the package's list of provides information.

By doing this, RPM reduces the need for package builders to manually add dependency information to their packages. However, there are times when RPM's automatic dependency processing may not be desirable. In those cases the autoreqprov tag can be used to disable automatic dependency processing.

To disable automatic dependency processing, add the following line:

AutoReqProv: no

(Note that 0 may be used instead of no.) Although RPM defaults to performing automatic dependency processing, the effect of the autoreqprov tag can be reversed by changing no to yes. (1 may be used instead of yes.)

13.2.4. Architecture- and Operating System_Specific Tags

As RPM gains popularity, more people are putting it to work on different types of computer systems. While this would not normally be a problem, things start to get a little tricky when either of the following situations becomes commonplace:

• A particular operating system is ported to several different hardware platforms, or architectures.
• A particular architecture runs several different operating systems.

The real bind occurs when RPM is used to package software for several of these different system environments. Without methods of controlling the build process based on architecture and operating system, package builders that develop software for more than one architecture or operating system will have a hard time indeed. The only alternative would be to maintain parallel RPM build environments and accept all the coordination headaches they would entail.

Fortunately, RPM makes it all easier than that. With the tags described in the following sections, it's possible to support package building under multiple environments, all from a single set of sources, patches, and a single spec file. For a more complete discussion of multiarchitecture package building, see Chapter 19, "Building Packages for Multiple Architectures and Operating Systems."

The excludearch tag directs RPM to ensure that the package does not attempt to build on the excluded architecture(s). The reasons for preventing a package from building on a certain architecture might include the following:

• The software has not yet been ported to the excluded architecture.
• The software would serve no purpose on the excluded architecture.

An example of the first case might be that the software was designed based on the assumption that an integer is a 32-bit quantity. Obviously, this assumption is not valid on a 64-bit processor.

In the second case, software that depended on or manipulated low-level features of a given architecture should be excluded from building on a different architecture. Assembly language programs would fall into this category.

One or more architectures may be specified after the excludearch tag, separated by either spaces or commas. Here is an example:

ExcludeArch: sparc alpha