7.4. Conflicting binary packages - Conflicts

When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the “Unpacked” state but allows both packages to be unpacked at the same time.

If one package is to be unpacked, the other must be removed first. If the package being unpacked is marked as replacing (see Overwriting files and replacing packages - Replaces, but note that Breaks should normally be used in this case) the one on the system, or the one on the system is marked as deselected, or both packages are marked Essential, then dpkg will automatically remove the package which is causing the conflict. Otherwise, it will halt the installation of the new package with an error. This mechanism is specifically designed to produce an error when the installed package is Essential, but the new package is not.

A package will not cause a conflict merely because its configuration files are still installed; it must be at least “Half-Installed”.

A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature.

Normally, Breaks should be used instead of Conflicts since Conflicts imposes a stronger restriction on the ordering of package installation or upgrade and can make it more difficult for the package manager to find a correct solution to an upgrade or installation problem. Breaks should be used

• when moving a file from one package to another (see Overwriting files and replacing packages - Replaces),

• when splitting a package (a special case of the previous one), or

• when the breaking package exposes a bug in or interacts badly with particular versions of the broken package.

Conflicts should be used

• when two packages provide the same file and will continue to do so,

• in conjunction with Provides when only one package providing a given virtual facility may be unpacked at a time (see Virtual packages - Provides),

• in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages) or that must prevent both packages from being unpacked at the same time, not just configured.

Be aware that adding Conflicts is normally not the best solution when two packages provide the same files. Depending on the reason for that conflict, using alternatives or renaming the files is often a better approach. See, for example, Binaries.

Neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Having similar functionality or performing the same tasks as another package is not sufficient reason to declare Breaks or Conflicts with that package.

A Conflicts entry may have an “earlier than” version clause if the reason for the conflict is corrected in a later version of one of the packages. However, normally the presence of an “earlier than” version clause is a sign that Breaks should have been used instead. An “earlier than” version clause in Conflicts prevents dpkg from upgrading or installing the package which declares such a conflict until the upgrade or removal of the conflicted-with package has been completed, which is a strong restriction.