From Fedora Project Wiki
(→‎Hints: rewording)
 
(30 intermediate revisions by 4 users not shown)
Line 1: Line 1:


= Implementation Status / Todo =
= Implementation Status / Todo =
* RPM
** --whatrecommends and friends
* DNF:
** add configuration option 'install_weak_deps' with allowed values auto/always/never for dealing with weak dependencies. The auto will be set by default. Auto will install recommended and supplemented packages only if there's no conflict.
** add 'install_weak_deps' attribute to dnf.conf.Conf
** implement command 'install-weakdep' which install recommended packages of already installed package and suggested packages.
** implement plugin: when package is removed then it will added to recommend exclude set and will not be pulled in when another package recommends it during installation.
** when showing the transaction confirmation overview, include packages that are recommended/suggested but will not be installed
** (?) in the same overview, maybe show a section saying which packages can be removed from the transaction without breaking it? (they are in only because they are recommended)


* Check repository meta data if createrepo is on proper version
= Weak Dependencies Policy =


== Introduction ==


Weak dependencies are basically variant of the Requires: tag and are matched against (virtual) Provides: and package names using Epoch-Version-Release range comparisons - just like regular Requires.
They come in two strengths: "weak" and "hint" and two directions "forward" (as are Requires) and "backwards":


= Weak Dependencies =
{|
(Actual policy)
|
| Forward
| Backward
|-
| Weak  
| Recommends:
| Supplements:
|-
| Hint
| Suggests:
| Enhances:
|}


== Motivation ==
Weak dependencies allow smaller minimal installations while keeping the default installation feature rich. They also allow packages to specify preference for specific providers while maintaining the flexibility of virtual provides - e.g. preferring ruby vs jruby, community-mysql vs mariadb
* for conservative users who wants the system minimal (Weak deps)
* specify preference of provides - ruby vs jruby, community-mysql vs mariadb (Weak deps hints)


== Package preference ==
== Weak dependencies ==
Real life example:
 
Weak dependencies are by default treated similarly to regular Requires:. Matching packages are added to the transaction. If adding the package would lead to an error dnf will ignore the dependency. This allows users to exclude packages that would be added by weak dependencies or remove them later. (Future versions of dnf might also allow to switch weak deps off on the command line)
Weak dependencies though may only be used if not installing the target package will not create an error. But it is OK to create packages that have very limited functionality without adding some of its weak requirements. Weak dependencies should be used where it allows to minimize the installation for reasonable use cases - especially for building virtual machines or containers that have a single purpose only and do not require the full feature set of the package.
 
Typical use cases for weak dependencies are:
 
* Documentation
** Documentation viewers if missing them is handled gracefully
* Examples
* Plug-ins or add-ons
** Support for file formats
** Support for protocols
** ...
 
== Hints ==
 
Hints are by default ignored by dnf. They may be used by GUI tools to offer add-on packages that are not installed by default but might be useful in combination with the installed packages. The requirements of the main use cases of a packages should not just be pointed at with Hints but by weak or even strong dependencies.
 
== Package Preference ==
Dnf (or more precisely libsolv) will use weak dependencies and hints to decide which package to use if there are multiple equally valid packages to choose from. In these cases packages that are pointed at by dependencies from installed or to be installed packages are preferred. Note, that this does not alter the rules of dependency resolutions - e.g. weak dependencies cannot enforce a older version of a package to be chosen.
 
If there are multiple (typically virtual) providers for a dependencies the requiring package may add a Suggests: to hint for the preferred package. Enhances: should only be used for the rare occasion when the main package and other providers agree that adding the hint to the required package is for some reason the cleaner solution.
 
=== Real life example ===


<code>
<code>
Line 27: Line 72:
</code>
</code>


If you want to prefer mariadb instead of community-mysql -> add <code>Suggests: mariadb</code> into Pkg A spec
If you want to prefer mariadb instead of community-mysql -> add <code>Suggests: mariadb</code> into Pkg A spec.
or <code>Enhances: A</code> into Pkg mariadb spec. With help of Rich dependencies you could also change <code>Requires: mariadb OR mysql</code>
in Pkg A - similar concept to Gentoo distro approach.


== Weak deps hints ==
== Forward vs Backward Dependencies ==
These are used as package preference. Target packages will be installed if packages in the transaction requires one of their Provides - no configuration in DNF (it's a hint for depsolver).


=== Supplements: ===
Forward dependencies are - as Requires - evaluated for packages that are being installed. The best of the matching (fulfilling) packages are also installed. For reverse dependencies the packages containing the dependency are installed if a matching package is getting installed also.
forward relation, used for langpacks with combination of AND operator from Rich dependencies.


=== Enhances: ===
In general forward dependencies should be used. Add the dependency to the package getting the other package added to the system.
backward relation


== Weak deps ==
Reverse dependencies are mainly designed for 3rd party vendors which can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages. Within Fedora the control over which packages a package requires should stay with the package maintainer. But there are cases when it is easier for the requiring package not needing to care about all add-ons. In this cases reverse dependencies may be used with the agreement of the package maintainer of the targeted package.
Packages with weak dependency relation are optional and main packages that recommended them should run independently. The user will choose whether they will be installed or not.


== Recommends: ==
Note, that EPEL or other third party repositories may have (and are encouraged to have) a different policy.
forward relation


== Suggests: ==
== Compatibility ==
backward relation


== Where to use forward and backward dependencies ==
Weak dependencies are not supported and just ignored by yum . Therefore packages must not rely on weak dependencies up to Fedora 22 where yum is still supported. While hints can still be used Requires: must not be replaced by Recommends: until Fedora 23.
The forward weak dependencies should be used when possible. If the main package doesn't know about extensions then backward relation should be used. For packages inside EPEL repository enhancing packages in RHEL repository it makes sense to use reverse dependencies.

Latest revision as of 17:36, 28 May 2015

Implementation Status / Todo

  • RPM
    • --whatrecommends and friends
  • DNF:
    • add configuration option 'install_weak_deps' with allowed values auto/always/never for dealing with weak dependencies. The auto will be set by default. Auto will install recommended and supplemented packages only if there's no conflict.
    • add 'install_weak_deps' attribute to dnf.conf.Conf
    • implement command 'install-weakdep' which install recommended packages of already installed package and suggested packages.
    • implement plugin: when package is removed then it will added to recommend exclude set and will not be pulled in when another package recommends it during installation.
    • when showing the transaction confirmation overview, include packages that are recommended/suggested but will not be installed
    • (?) in the same overview, maybe show a section saying which packages can be removed from the transaction without breaking it? (they are in only because they are recommended)

Weak Dependencies Policy

Introduction

Weak dependencies are basically variant of the Requires: tag and are matched against (virtual) Provides: and package names using Epoch-Version-Release range comparisons - just like regular Requires. They come in two strengths: "weak" and "hint" and two directions "forward" (as are Requires) and "backwards":

Forward Backward
Weak Recommends: Supplements:
Hint Suggests: Enhances:

Weak dependencies allow smaller minimal installations while keeping the default installation feature rich. They also allow packages to specify preference for specific providers while maintaining the flexibility of virtual provides - e.g. preferring ruby vs jruby, community-mysql vs mariadb

Weak dependencies

Weak dependencies are by default treated similarly to regular Requires:. Matching packages are added to the transaction. If adding the package would lead to an error dnf will ignore the dependency. This allows users to exclude packages that would be added by weak dependencies or remove them later. (Future versions of dnf might also allow to switch weak deps off on the command line) Weak dependencies though may only be used if not installing the target package will not create an error. But it is OK to create packages that have very limited functionality without adding some of its weak requirements. Weak dependencies should be used where it allows to minimize the installation for reasonable use cases - especially for building virtual machines or containers that have a single purpose only and do not require the full feature set of the package.

Typical use cases for weak dependencies are:

  • Documentation
    • Documentation viewers if missing them is handled gracefully
  • Examples
  • Plug-ins or add-ons
    • Support for file formats
    • Support for protocols
    • ...

Hints

Hints are by default ignored by dnf. They may be used by GUI tools to offer add-on packages that are not installed by default but might be useful in combination with the installed packages. The requirements of the main use cases of a packages should not just be pointed at with Hints but by weak or even strong dependencies.

Package Preference

Dnf (or more precisely libsolv) will use weak dependencies and hints to decide which package to use if there are multiple equally valid packages to choose from. In these cases packages that are pointed at by dependencies from installed or to be installed packages are preferred. Note, that this does not alter the rules of dependency resolutions - e.g. weak dependencies cannot enforce a older version of a package to be chosen.

If there are multiple (typically virtual) providers for a dependencies the requiring package may add a Suggests: to hint for the preferred package. Enhances: should only be used for the rare occasion when the main package and other providers agree that adding the hint to the required package is for some reason the cleaner solution.

Real life example

Pkg A: Requires: mysql

Pkg mariadb: Provides: mysql

Pkg community-mysql: Provides: mysql

If you want to prefer mariadb instead of community-mysql -> add Suggests: mariadb into Pkg A spec.

Forward vs Backward Dependencies

Forward dependencies are - as Requires - evaluated for packages that are being installed. The best of the matching (fulfilling) packages are also installed. For reverse dependencies the packages containing the dependency are installed if a matching package is getting installed also.

In general forward dependencies should be used. Add the dependency to the package getting the other package added to the system.

Reverse dependencies are mainly designed for 3rd party vendors which can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages. Within Fedora the control over which packages a package requires should stay with the package maintainer. But there are cases when it is easier for the requiring package not needing to care about all add-ons. In this cases reverse dependencies may be used with the agreement of the package maintainer of the targeted package.

Note, that EPEL or other third party repositories may have (and are encouraged to have) a different policy.

Compatibility

Weak dependencies are not supported and just ignored by yum . Therefore packages must not rely on weak dependencies up to Fedora 22 where yum is still supported. While hints can still be used Requires: must not be replaced by Recommends: until Fedora 23.