Status of weak dependencies support in Fedora 21+
jsilhan at redhat.com
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 redhat.com> 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:
> > http://rpm.org/wiki/PackagerDocs/Dependencies
> 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
FYI I have added to DNF github wiki page  how to report different kinds of bugs.
More information about the devel