PackagingDrafts/ProvidesPreferences

Package Provides Priorities

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 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.

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 to packages are on the same feature-rich level and no package is strictly preferred among the users.

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 following approaches:

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.