PackagingDrafts/ProvidesPreferences

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 within 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 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 need 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. Distribution preferred packages are listed in one place. Each of them is defined by Suggests tag in fedora-release package. E.g. to prioritize package B on global level, amend the fedora-release.spec accordingly:

Name: fedora-release
Suggests: B

After rebuilding the fedora-release package, a package manager like DNF, PackageKit or Gnome Software would always pick 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 two packages that deserve to be globally preferred in Fedora:

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