Package Provides Priorities
Introduction
In PRM world the packages that take advantage of Provides tag and two packages provides the same name without the version specified, they are treated equally. No one has greater preference than the other and so the dependency solver like the one in DNF or PackageKit can practically choose any of them during the resolution. Let's consider following definition of packages in the repository for examples in this document:
Name: A
Provides: featureX
Name: B
Provides: featureX
Name: C
Requires: featureX
By installation the package C, the package installed along with C could be either A or B. To specify the preference which package should be pulled into transaction could be defined by three entities - Users, Package maintainers and Distribution.
User preference
ser can influence which package of the two "same" package dependencies should be installed. When you install the packages using command line package manager like DNF, you can prefer the provide dependency by explicitly specifying it from command line, i.e. executing "dnf install C B" instead of just "dnf install C". Considering the package definition above, package B and C will end on your system.
This method is recommended when to packages are on the same feature-rich level and one package is not strictly preferred among the users.
Package Maintainer Preference
Now we are getting to the package preference on packager / maintainer level. To prefer one package over another, one can use one of the following approaches. The changes needs to be done in the package(s) itself.
Name: C
Requires: featureX
Suggests: B
or
Name: B
Provides: featureX
Enhances: C
or
Name: A
Provides: featureX = 1
Name: B
Provides: featureX = 2
From semantic point of view these definitions are equivalent but generally you should go with the first case. See more about weak dependencies here [1].
This approach is advised when there are only a few packages requesting the feature of packages, especially when the maintainer of all components is the same.
Distribution preference
Let's sum up the sections above. Users / packagers has to do the hard work. If some package is preferred from distribution point of view, it does not make no sense at all to let every single user type the preferred package to the command line. Some counts for packagers. When one component has the same provide as another component and a lot of packages demands just the shared Provide, then all packages requiring the Provide should be edited. That means a lot of work and trouble. The distribution preferred packages should be in fedora-release package defined as Suggests tags, i.e. in fedora-release.spec:
Name: fedora-release
Suggests: B
...
After rebuilding the fedora-release package, package manager like DNF, PackageKit or Gnome Software would pick always package B to satisfy package C dependencies from packages definitions in <introduction> without additional user's or packager's intervention.
So far there have been identified three packages that deserves to be globally preferred in Fedora:
- ruby should be preferred over jruby (both provides ruby(runtime_executable))
- mariadb should be preferred over community-mysql (both provides mysql)
- sendmail should be preferred over esmtp (both provides /usr/sbin/sendmail)
Distribution preference in fedora-release package should be used in case a lot of packages requires the shared provide of other packages while only package was decided to be default feature representative for Fedora users.