Package Provides Preferences
In PRM ecosystem, 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 within 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 or Distribution.
Motivation of this guide line is to define systematic solution of specifying package preferences while not depending on hard-coded complex hacks within package managers but rather reuse existing features of RPM.
User preference
User or admin 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 the packages are on the same feature-rich level and no package is strictly prioritized among users. Note that user preference is the strongest, i.e. the desired dependency will always get installed no matter whether other package was preferred on Maintainer or Distribution level.
Package Maintainer Preference
Now we are getting to the package preference on packager / maintainer level. That means changes needs to be done in the package(s) itself. To prefer one package over another, you can use one of the three following approaches:
- adding forward hint to the package demanding one of the Provides
Name: C
Requires: featureX
Suggests: B
- adding backward hint to the dependency
Name: B
Provides: featureX
Enhances: C
- specifying the version in Provides tag - the highest version is picked
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.
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. This method does not unintentionally pull in package that no component demands.
Distribution preference
In sections above users or packagers needed to specify the prioritized package. If some package is preferred from distribution point of view, it makes no sense at all to let every single user type the preferred package on the command line or let the packager change spec file and then rebuild all packages demanding prioritized feature. The distribution preferred packages are listed in one place. Each of them is defined by Suggests tags in fedora-release package. I.e. to prioritize package B on global level, amend the fedora-release.spec accordingly:
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 without additional user's or packager's intervention.
At the time of writing this draft 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. This method does not unintentionally pull in package that no component demands.