Conflicts Guidelines

Keep in mind that implicit conflicts are NEVER acceptable. If your package conflicts with another package, then you must either resolve the conflict, or mark it with Conflicts:.

Some software can utilize other optional software applications if present, but do not require them to be installed. If they are not installed, the software will still function properly. However, if those other "optional applications" are too old, then the software won’t work. This is an acceptable use of the Conflicts: field. The packager must document the reason in a comment above the Conflicts: field:

Example:

If the software links to the libraries of another package, it must use Requires: instead of Conflicts: to mark that dependency. Also, if the software does not function properly without another package being installed, it must use Requires: instead of Conflicts:.

The packager should ask:

If the package (at the correct version) in Conflicts: is not present, will my package be functional?

If the answer is yes, then it is probably a valid use of Conflicts:. If the answer is no, then it is almost certainly a better case for Requires:.

For example, if foo-game needs libbar to run, but will not work with libbar that is older than 1.2.3:

WRONG: Conflicts: libbar < 1.2.3
RIGHT: Requires: libbar >= 1.2.3
Packagers should keep usage of Conflicts: to a bare minimum. Only upgrading from two previous release of Fedora is supported, so Conflicts against older packages than that, while technically correct, are unnecessary, and should not be included.

If contents from one package are split into a separate package the new package usually contains files that also appear in the original package which might lead to a implicit conflict between the files in the new package and the original package. Where the new package depends on the original package, this can be resolved with a versioned Requires:

If the new package should be installable independently of whether the original package is installed, a versioned conflict is allowed:

In both of these cases, the new version of the original package should be updated to not contain the conflicting files and to depend on the new package (at least in all stable Fedora releases). This allows to install the latest releases of both packages without any problem. The Conflicts are only there to resolve the case where the new package is installed and the older version of the original package was already installed.

It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided.

In the specific case where multiple software components generate identically named (but incompatible) binaries, Fedora Packagers should make every effort to convince the upstreams to rename the binaries to resolve the conflict (see: Packaging:Conflicts#Binary_Name_Conflicts). However, if neither upstream is willing to rename the binaries to resolve the conflict, AND the binaries are not viable candidates for alternatives or environment modules (incompatible runtimes), as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager’s discretion. Both packages must carry Conflicts in this case.

Be aware, adding explicit Conflicts means that if any other packages depend on your package, you may be creating a chain-of-conflicts that could cause user pain. Please consider this as a last resort.

If the library is 100% ABI-compatible, you can use Packaging:EnvironmentModules[ Environment Modules] to let the user switch between them. If the library is not 100% ABI-compatible get one of the upstreams to rename. See Packaging:Conflicts#Approaching_Upstream[ Approaching Upstream] for ideas on persuasion. If neither upstream will budge open a ticket for FPC to evaluate what sort of hoops both packages would need to implement to not conflict at runtime.

When renaming or putting files into subdirectories, it is a good idea to try to get upstream to rename their conflicting files (for instance if they both had commands named %{_bindir}/trash). Doing some research about which has been around longer may be useful in this case but may or may not be persuasive to upstream.

If neither upstream renames, we would then approach other distributions (distributions-list[at]freedesktop.org is a good place to discuss this) about renaming that can be done in all distros. That helps end users going from one distro to another to have consistency. Length of time that the projects have been around, how popular each is, and numerous other factors may play a role in this decision. Once a decision is made, we would rename the Fedora packages to match.

Common names are allowed for standard commands since those will be the only commands to implement them. Standard commands include things provided for in published and widely implemented standards like POSIX and de facto standards such as a program that has traditionally been shipped with a certain filename as part of a large number of Unix variants. If in doubt, send a message to fedora-devel-list[at]redhat.com with details of what standards the command appears in, how long it’s been available on what Unix systems, and whether you’ve found any conflicting programs that implement a substantially different command with the same filename.