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.
- list packages targeted to installed by weak deps in DNF transaction
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.