Status of weak dependencies support in Fedora 21+

Jan Silhan jsilhan at
Wed Nov 12 13:38:04 UTC 2014

On 10. 11. 2014 at 10:31:55, Kevin Fenzi wrote:
> On Mon, 10 Nov 2014 10:34:16 +0100
> Jan Zelený <jzeleny at> wrote:
> > Dnf should already have full support of this feature, at least that
> > is the plan. Some people already tested it and so far it seems it
> > works as expected. The semantics is described here:
> > 
> >
> Well, if things are fully implemented then...
> 1. If there's a weak dep (reccomends or supplants) that generates a
> solving error, dnf drops that weak dep and goes on with no error?
> (I guess this case would be two packages recommending things that
> conflict or one recommending something and another package with a
> supplants for a different package)

Weak deps has been supported in libsolv for long time but nobody tried
this scenarios in dnf. AFAIK it will ends with error now - no packages

> 2. For 'very weak' deps (suggests, enhances) does dnf "show the
> matching packages as option to the user" ?

It doesn't show it but it could.

> 3. The page says "The depsolver may offer to treat the weak like very
> weak relations or the other way round" does dnf do that? or not?

DNF doesn't do that and never will. IMO that would be too hackish behavior.

> > Perhaps some folks would like to step up to help out with this?
> > Make a wiki page or document of various cases people might use it, make
> > a test copr with those cases? Draft a FPC guideline for using them?
> That would be really appreciated. All those can be done simultaneously with 
> the progressing adoption. I'm convinced we should use the test run in F21 to 
> actually know what we need to regulate/control. Writing guidelines without any 
> prior experience with the technology in Fedora is highly unlikely to do any 
> good (remember SCLs?).

I would be glad if the packagers/users come with undefined scenarios and file BZ
on DNF with:
* "[weak deps]" summary prefix
* post link to custom COPR, so we can reproduce it easily
* write "expected" result

then RPM team decides how DNF should act, change it accordingly and document
this case.

FYI I have added to DNF github wiki page [1] how to report different kinds of bugs.



More information about the devel mailing list