PackagingDrafts/WeakDependencies

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)

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:

backward relation

Where to use forward and backward dependencies

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.