Package Dependencies

Expressing dependencies

Package dependencies are fully expressed in the .spec file used to build a package. There are no other means to specify dependencies.

Means to express dependencies

Each package can express dependencies to other packages by defining symbolic names for Provides, Requires, and Conflicts.
These symbolic names are usually names of packages but can also be 'abstract' names not related to a package.

These symbolic names can be used to express capabilities which are unrelated to a specific package. For example, the capability MTA (mail transport agent) is provided by multiple packages. sendmail and postfix being the most prominent.

It is important to remember that all symbolic names (being package or abstract names) reside in the same namespace. When choosing an abstract name (e.g. for a capability) it must not conflict with another package name.

To express update dependencies in order to replace one (old) package with another (newer) package, the Obsoletes tag is used.

Facts for RPM dependencies

• Each package implicitly provides its name.
  There is no need to provide the package name, but other packages can require (or conflict with) the package name.
• A package can not conflict with a symbolic tag it provides.
  Since the package name is provided implicitly, a package can not conflict with itself.
• Obsolete works on real package names only.
  One can not obsolete a symbolic tag.
• Symbolic names, as used in Requires, Provides, and Conflicts, are case-sensitive.

Basic dependencies

Installing a new package

pac.spec
Name:	pac
Version:	1.0
Requires:
Provides:
Obsoletes:
Conflicts:

Updating a package

pac.spec
Name:	pac
Version:	1.1
Requires:
Provides:
Obsoletes:
Conflicts:

The matching name and the higher version make this an update for pac-1.0

Renaming a package

pac.spec
Name:	pac
Version:	1.1
Requires:
Provides:
Obsoletes:
Conflicts:

Strictly speaking, giving the old package name in the Provides: field is only needed if another package requires the old package name. However, the Provides: entry triggers the selection of the new package during update. It is this field which tells, I'm taking over for the old package. The Obsoletes: just ensures an atomic replacement so that no dependencies are broken. The Version: field is irrelevant here.

Splitting and Merging

Splitting off a sub-package

pac.spec
Name:	pac
Version:	1.1
Requires:
Provides:
Obsoletes:
Conflicts:

Splitting a package into two

pac.spec			pac-devel.spec
Name:	pac		Name:	pac-devel
Version:	1.1		Version:	1.1
Requires:			Requires:
Provides:			Provides:	pac:/file/from/pac
Obsoletes:			Obsoletes:
Conflicts:			Conflicts:

The example shown lists separate .spec files for pac and pac-devel. (Remember that RPM allows to define sub-packages from a 'master' package with a single .spec file.

The dependency resolution (installing both new packages) is done by YaST with the split-alias mentioned in Provides: of pac-devel.

It is up to the package maintainer to decide about dependencies between pac and pac-devel. For example, if one wants to split a library package into a main, a -devel, and a -doc package. The main and the -doc package are independant, but the -devel package requires the main package.

During an update, the aformentioned split-alias tag is important. YaST only updates already installed packages, in this case only the main package. Without the split-alias, this would remove files needed for development which were part of the old main package but are not in the new main package.

The given Provides: for pac now triggers this update dependency as it tells YaST also to install pac-devel even though it was not installed before.

!! split-alias tags are used by YaST only, RPM never sees them. !!

If a package is splitted in more than two packages, the split-alias tags must be mutually exclusive. It's the only way for YaST to correctly handle such update dependencies.

Merging a package

package.spec
Name:	package
Version:	1.1
Requires:
Provides:	pac
Obsoletes:	pac
Conflicts:

This is comparable to package rename. The new package must also incorporate the Provides and Obsoletes tags from the old package. This is needed to properly update from distribution before X.

Merging two packages into a new one

package.spec
Name:	package
Version:	1.1
Requires:
Provides:	pac1 pac2
Obsoletes:	pac1 pac2
Conflicts:

Handling alternatives

Non conflicting

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac		Provides:	Pac		Provides:	Pac
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:			Conflicts:			Conflicts:

All three package provide the capability Pac and can be installed in parallel.

(The upper case letter in Pac is choosen on purpose to distinguish this tag from a package. Such capabilities must be agreed upon within the OpenSUSE community. Ask on opensuse-packaging before inventing your own tag !).

Example: xdm and kdm provide capability 'Display-Manager'

Partially conflicting

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac		Provides:	Pac		Provides:	Pac
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:	secondpac		Conflicts:	firstpac		Conflicts:

The Conflicts express that only either firstpac or secondpac might be installed. But not both.

Mutually exclusive

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac		Provides:	Pac		Provides:	Pac
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:	secondpac thirdpac		Conflicts:	firstpac thirdpac		Conflicts:	firstpac secondpac

Only one of firstpac, secondpac, or thirdpac might be installed.