#2088 F31 Change – “dnf --best” as default behavior
Opened a month ago by jmracek. Modified 15 days ago

I would like to ask for an exception to the Changes policy for F30 Change proposal: https://fedoraproject.org/wiki/Changes/DNF_Default_Best.

The change should not only improve security, but also will lead to much easily discovering issues in release. The original issue arise from Modularity team as an important key for modular integrity.


I asked Jaroslav to take this directly to FESCo since we're so far into the schedule that going through the normal process would mean it doesn't even get to FESCo until after the code complete (testable) deadline.

I have concerns about changing the behavior of a key system component this late in the process, even though it seems to be a pretty minor change. I've also asked the QA team to weigh in on this ticket.

Reading this change proposal I'm +1 conditionally on providing a clear Contingency mechanism and Contingency deadline. Aka let's put it in F30 now but have a documented process of revoking it.

This being late also means that there was no discussion or announcement on devel. We should make sure that happens so we can revert this if we see some valid concerns there.

@adamwill What are your thoughts on this?

+1 to the change. However, the option name --nobest sounds to me badly chosen. The yum --skip-broken was a lot more descriptive.

See mail to test@ list. I agree with @till , I think I'm fine with the behaviour, but would prefer --skip-broken both as it's a more descriptive name and it's the name people know from yum. (Or we could have both names, of course).

Questions/thoughts I have here:

  • Are we risking a situation where in an attempt to make things more secure, users simply don't upgrade at all and miss all security updates? dnf dependency errors can be essentially impossible for a non-expert user to figure out, and can be very specific to a particular system. Resolving this type of error may also require switching from the GNOME Software UI to the command line.

  • Are we expecting the breakages that are uncovered here to mostly be our breakages - problems in the Fedora repositories - or problems with 3rd party repositories and locally installed packages? Breakages that are our own fault will hopefully be reported and fixed quickly, but we don't have much control over the other types of breakage.

  • How is this going to interact with PackageKit and it's usage of libdnf? Do we need to change something there so we have consistent behavior? It would be confusing if we were in a situation where PackageKit does one thing and 'dnf' another.

  • We should check carefully that the options being used for the test transaction and the actual after-reboot transaction are the same when doing 'dnf system-upgrade' and upgrading via the UI in GNOME Software.

IIRC yum used to print an informational message about what was going on, and mention --skip-broken, when there were dependency issues. Perhaps dnf could do the same (if it doesn't already).

From the Change page:

The purpose of the --nobest switch (as a shorthand for --setopt=best=0) is to make it easy for the user to override the default setting when needed, and it will also be suggested in the DNF output when a dependency error occurs.

So dnf doesn't do this yet (at least in the version in F30), but it will.

How is this going to interact with PackageKit and it's usage of libdnf? Do we need to change something there so we have consistent behavior? It would be confusing if we were in a situation where PackageKit does one thing and 'dnf' another.

From my quick reading of the diff, this change changes the dnf frontend to use --best as default and doesn't change the libdnf solver default behaviour. This means that it doesn't change how the solver behaves for PackageKit (and gnome-software that uses PackageKit), leaving it using the old behaviour there.

+1 to the change. However, the option name --nobest sounds to me badly chosen. The yum --skip-broken was a lot more descriptive.

The option --skip-broken has different behavior from --nobest. If you use --skip-broken, the packages with broken dependencies are removed from the transaction. If you use --nobest, you don't skip any packages, but some of them are installed in a lower version (the transaction is not limited to the best candidates only).

To be honest, being rawhide user, I would appreciate if best will stay 0, because otherwise I won't ever upgrade my system (because some packages always have some broken deps) ;)

See mail to test@ list. I agree with @till , I think I'm fine with the behaviour, but would prefer --skip-broken both as it's a more descriptive name and it's the name people know from yum. (Or we could have both names, of course).

We tried to avoid to use --skip-broken to set best option to False, because the option is already used to set strict configuration to False.

To be honest, being rawhide user, I would appreciate if best will stay 0, because otherwise I won't ever upgrade my system (because some packages always have some broken deps) ;)

I think that rawhide is getting more stable therefore the impact should be lower that used to be. Anyway anyone can open /etc/dnf/dnf.conf and set best=true to best=false. Then the old behavior will be 100% restored.

Metadata Update from @psabata:
- Issue tagged with: meeting

a month ago

I prefer to describe behavior using libsolv testcase (because you can easily play with it).

repo system 0 empty
repo rawhide 0 testtags <inline>
#>=Pkg: puppet 5 1 noarch
repo custom 0 testtags <inline>
#>=Pkg: app 1 1 noarch
#>=Req: puppet
#>=Pkg: app 2 1 noarch
#>=Req: puppet >= 6
#>=Pkg: puppet 6 1 noarch
#>=Req: something-non-existing-yet

system x86_64 rpm system

poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes

job install name app
result transaction,problems <inline>
#>install app-1-1.noarch@custom
#>install puppet-5-1.noarch@rawhide

nextjob

job install name app [forcebest]
result transaction,problems <inline>
#>problem 1d63b840 info nothing provides something-non-existing-yet needed by puppet-6-1.noarch
#>problem 1d63b840 solution bf4b808e deljob install name app [forcebest]

Previously, we would be able to install user some older version of app because the new one is broken for some reason. While with new behavior, we will error out. I think people do like when dependency resolver actually finds solution for them (even if installing older version).

Or is it general behavior of DNF to do something over-strict so that users would end up resolving dependencies themselves? See https://bugzilla.redhat.com/show_bug.cgi?id=1677746 for example.

From the yesterday's meeting:

  * There are too many things to consider. We will discuss this in the
    ticket for another week.  (contyk, 17:02:34)

This was discussed in today's FESCo meeting:
ACTION: bowlofeggs will file an RFE for better error messages from dnf
REJECTED: Waiting for one more week (+2, 0, -3)
AGREED: Feature is postponed to F31, without accepting or
rejecting. We need more information from the Change owners about
specific cases that this solves (+6, 0, 0)

Metadata Update from @zbyszek:
- Issue untagged with: meeting

21 days ago

Login to comment on this ticket.

Metadata