Implementation Status / Todo

Check repository meta data if createrepo is on proper version
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' optional argument for dnf.Base.install/update methods
- implement command 'install-recommended' 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

Motivation

for conservative users who wants the system minimal (Weak deps)
specify preference of provides - ruby vs jruby, community-mysql vs mariadb (Weak deps hints)

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

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 depenency. This allows users to exclude packages that would be added by weak dependencies. In addition dnf can be told with XXX to ignore weak dependencies all together.

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 are not useful without adding some of its weak requirements. Weak dependencies should be used were 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
- Support for file formats
- Support for protocols
- ...

Hints

Direction

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.

Package Preference

Package preference

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 or Enhances: A into Pkg mariadb spec. With help of Rich dependencies you could also change Requires: mariadb OR mysql in Pkg A - similar concept to Gentoo distro approach.

Weak deps hints

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 relation, used for langpacks with combination of AND operator from Rich dependencies.

Enhances:

backward relation

Weak deps

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:

forward relation

Suggests: