#2168 F31 Self-Contained Change: DNF Make Best Mode the Default
Closed: Rejected 3 months ago by ignatenkobrain. Opened 3 months ago by bcotton.

Currently, DNF prefers clean dependency resolution over package updates; a package (almost) silently won't get updated to a newer version if the new version has dependency problems. DNF will be changed to prefer updates and fail if they have dependency resolution issues, while the failure has a temporal or permanent workaround hint for users who want to use the older behavior.

Note: this was previously considered for Fedora 30 in fesco#2088.


Did actually anything change since last time this was rejected? Looking at the diff on the wiki, it seems that only wording was fixed a bit, no improvements have been made related to UX. So I am -1 for now.

Just for an idea of what --best does. I had gone a few days without updating a system here.

'sudo dnf update':
Transaction Summary
================================================================================
Install 14 Packages
Upgrade 104 Packages
Remove 5 Packages

'sudo dnf --security update':
Transaction Summary
================================================================================
Upgrade 3 Packages

'sudo dnf --best update':
Error:
Problem 1: package yum-langpacks-0.4.5-10.fc30.noarch requires python2-langtable, but none of the providers can be installed
- package fedora-obsolete-packages-30-44.noarch obsoletes python2-langtable < 0.0.43-3 provided by python2-langtable-0.0.41-2.fc30.noarch
- cannot install the best update candidate for package yum-langpacks-0.4.5-10.fc30.noarch
- cannot install the best update candidate for package fedora-obsolete-packages-30-43.noarch
Problem 2: problem with installed package yum-langpacks-0.4.5-10.fc30.noarch
- package yum-langpacks-0.4.5-10.fc30.noarch requires python2-langtable, but none of the providers can be installed
- package fedora-obsolete-packages-30-44.noarch obsoletes python2-langtable < 0.0.43-3 provided by python2-langtable-0.0.41-2.fc30.noarch
- cannot install the best update candidate for package python2-langtable-0.0.41-2.fc30.noarch
(try to add '--skip-broken' to skip uninstallable packages)

So there were several updates available, 3 of which were security updates, and --best just gives errors which certainly do not convey that I am missing security updates if I don't fix this immediately. I would consider this actively harmful for the fedora user base.

-1 here

So, a few thoughts/notes here:

  • I agree that experence isn't good, but note that it does say to add '--skip-broken' there... did you try that?

  • The change indicates that the output will be changed to have:
    "(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)"
    I wonder if 'best' shouldn't really be named 'newest', as it always means the rpm newest package right?

  • I realize that dnf is a very important base package for us, but should we really be telling them what to do here? Upstream changes in other packages are often not changes, or run by us for our approval.

I realize that dnf is a very important base package for us, but should we really be telling them what to do here? Upstream changes in other packages are often not changes, or run by us for our approval.

I thought the same thing, but changed my mind. I think it's appropriate for FESCo because it's about setting a default on Fedora. It doesn't require upstream or other distros to change their default. If, for example, I was the maintainer of the dnf package, this would be more obvious, but the fact that the upstream devs are also the Fedora maintainers make it blurrier.

Well, the other downstream of dnf (rhel8) does use --best by default. So, I think one of the main reasons they wanted this is to reduce their maint burden and have both fedora/rhel behave the same way. That said, I don't know how much overhead there is to keep this seperate for the two downstreams. (Just a patch in one? a build time setting?)

AFAIK the entire dependency resolver code is different with/without best and having a different dependency resolver on rhel8 and fedora is a burden.

AFAIK the entire dependency resolver code is different with/without best and having a different dependency resolver on rhel8 and fedora is a burden.

Note that the proposal, as it stands, is that GNOME Software (via PackageKit) keeps using --nobest style resolution, so that style of resolution would still need to be maintained in libdnf.

(It would not be a lot of work to switch PackageKit over, I think, but there is a strong UX question of what happens when things fail... I don't really see it as tenable to throw up complicated error messages in a dialog and expect users to fix their system or report bugs.)

Sorry, but I'm -1 too.

Some specific considerations:

other downstream of dnf (rhel8) does use --best by default

That's important, and it's always better to minimize discrepancies. But RHEL is a fundamentally different beast. People buy RHEL to have stability and a strictly curated repo of packages. People install Fedora for development, and experimentation, and we have coprs, add-on repos that shall not be named, and a much larger set of packages in the repo. We must expect to have dependency breakage much more frequently.

AFAIK the entire dependency resolver code is different with/without best and having a different dependency resolver on rhel8 and fedora is a burden.

The other code is also used. The recommendation to use --nobest would be emitted on every failed upgrade, so users will be using that codepath anyway.

I think it's appropriate for FESCo because it's about setting a default on Fedora.

Agreed. The difference is a single line in dnf.conf. Even if the upstream switched, we may and should override the setting if something different is appropriate for Fedora.

But the most important reason is the actual experience of using dnf --best. The result is often a wall of impenetrable text. It's is very hard to figure out which package is the offender. In fact the "bad" package may not be named in the report at all (see https://bugzilla.redhat.com/show_bug.cgi?id=1729465 for a recent example). This output is not actionable by users, and --best will make the experience of using Fedora worse without any significant benefit to developers.

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

3 months ago

We have talked about this on today's FESCo meeting:

AGREED: REJECTED (+2, 0, -7) (ignatenkobrain, 15:41:21)

Metadata Update from @ignatenkobrain:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata