From Fedora Project Wiki
Line 68: Line 68:
At the time of writing this draft there have been identified three packages that deserves to be globally preferred in Fedora:
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)'')
* '''ruby''' should be preferred over '''jruby''' (both provides '''ruby(runtime_executable)''')
* ''mariadb'' should be preferred over ''community-mysql'' (both provides ''mysql'')
* '''mariadb''' should be preferred over '''community-mysql''' (both provides '''mysql''')
* ''sendmail'' should be preferred over ''esmtp'' (both provides ''/usr/sbin/sendmail'')
* '''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.''
''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.''

Revision as of 20:17, 18 November 2015

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.

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

  • adding forward hint to the package demanding one of the Provides
Name: C
Requires: featureX
Suggests: B
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

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