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 '='. Spaces are required around the numeric operator to separate the operator from the package name.
The full syntax for specifying a dependency on an epoch, version and release is
[epoch:]version[-release]
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 '-'
For example,
Requires: perl >= 9:5.00502-3
specifies
epoch=9 version=5.00502 release=3
The epoch (if present) is a monotonically increasing integer, neither the version or the release can contain the '-' hyphen character, and the dependency parser does not permit white space within a definition. Unspecified epoch and releases are assumed to be zero, and are interpreted as "providing all" or "requiring any" value.
The release tag is usually incremented every time a package is rebuilt for any reason, even if the source code does not change. For example, changes to the specfile, compiler(s) used to build the package, and/or dependency changes should all be tracked by incrementing the release. The version number, on the other hand, is usually set by the developer or upstream maintainer, and should not be casually modified by the packager.
Version numbering should be kept simple so that it is easy to determine the version ordering for any set of packages. If the packager needs to separate a release from all other releases that came before it, then the epoch, the most significant part of package ordering, can be changed.
The algorithm that RPM uses to determine the version ordering of packages is simple and developers are encouraged not to rely on the details of its working. Developers should keep their numbering scheme simple so any reasonable ordering algorithm would work. The version comparison algorithm is in the routine rpmvercmp() and it is just a segmented strcmp(3). First, the boundaries of the segments are found using isdigit(3)/isalpha(3). Each segment is then compared in order with the right most segment being the least significant. The alphabetical portions are compared using a lexical graphical ascii ordering, the digit segments strip leading zeroes and compare the strlen before doing a strcmp. If both numerical strings are equal, the longer string is larger. Notice that the algorithm has no knowledge of decimal fractions, and perl-5.6 is "older" than perl-5.00503 because the number 6 is less than the number 503.
The concept of "newer" used by rpm to determine when a package should be upgraded can be broken if version format changes oddly, such as when the version segments cannot be meaningfully compared.
Example of a bad format change: 2.1.7Ax to 19980531
The date may be the older version, but it is numerically greater 2 so it is considered newer :(
Example of a bad increment: 2.1.7a to 2.1.7A
The 'a' (ASCII 97) is compared against 'A' (ASCII 65), making 2.1.7a the newer version.
Stick to major.minor.patchlevel using numbers for each if you can. Keeps life simple :-)
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.
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
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.
The macros: __find_provides, __find_prereq, __find_requires, __find_conflicts, __find_obsoletes, if they exist, are expanded to the name of a program to exec. For each package, the program receives the glob'ed files manifest on stdin and returns dependencies on stdout. The discovered dependencies are parsed exactly as if they were found after
Provides: PreReq: Requires: Conflicts: Obsoletes:
/bin/sh # file existence libc.so.6 # soname existence foo <= 1:2.3-4 # versioned package perl5(Apache) <= 1.2 # versioned namespace
The default rpm configuration has only __find_provides /usr/lib/rpm/find-provides __find_requires /usr/lib/rpm/find-requires which can be overridden (or even undefined) within a spec file.
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 language 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 \verbatim /usr/lib/rpm/find-{provides,requires}
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 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.
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.
You have a bag of features that are injected into a package in a non-ordered fashion, and you want to have the package name-version-release be able to:
1) identify the "root version" of the source code. 2) identify the handful of features that are in that branch of the package. 3) preserve sufficient ordering so that packages upgrade without the use of --oldpackage.
A simple (but possibly not adequate) scheme to achieve this is:
Name: foo Version: <the "root version" of the source code> Release: <release instance>.<branch>
where the release instance is something like YYYMMMDD or some linear record of the number of builds with the current tar file, it is used to preserve ordering when necessary.
Another alternative scheme might be:
Name: foo Epoch: <branch> Version: <the branch specific version of the code> Release: <release instance>
BuildRequires: BuildConflicts: BuildPreReq: