- 1 Conflicts Guidelines
Author: Tom 'spot' Callaway
Initial Draft: Tuesday Dec 5, 2006
Last Revised: Tuesday Apr 10, 2007
Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the
Acceptable Uses of Conflicts:
As a general rule, Fedora packages must NOT contain any usage of the
Conflicts: field. This field is commonly misused, when a
Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the
Conflicts: field is appropriate and acceptable.
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: unrar < 2.0
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
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
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.
Compat Package Conflicts
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.
There are many types of files which can conflict between multiple packages. Fedora strongly discourages using
Conflicts: to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions):
Man Page Name Conflicts
- Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz)
- Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz)
Library Name Conflicts
- Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/.
Header Name Conflicts
- Put the headers in a subdirectory of /usr/include.
Binary Name Conflicts
- Convince upstream to rename the binaries to something less generic (or just less conflicting).
- In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case.
Other Uses of Conflicts:
If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the [wiki:Self:Packaging/Committee Fedora Packaging Committee] . If they agree, then, and only then can you use
Conflicts: in a Fedora package. Remember, whenever you use
Conflicts:, you are also required to include the reasoning in a comment next to the
Conflicts: entry, so that it will be abundantly clear why it needed to exist.