dnf4 has dnf-plugins-core and dnf-plugins. dnf5 has just dnf-plugins-core. At least dnf-plugins-core isn't obsoleted/replaced and dnf-plugins-core was introduced in the yum -> dnf upgrade because it was smaller, had core plugins without a lot of other dependencies. I think dnf5 should have that split as well. Either way the dnf4 variants aren't obsoleted/provided in an upgrade to dnf5 so the functionality they provided such as config-manager just disappears and ceases to work which is a poor experience and these need to be taken into account as in < F-41 dnf-plugins-core is part of the default install and having dnf-plugins-core v4 without dnf4 isn't useful. Reproducible: Always
Proposed as a Blocker for 41-beta by Fedora user pbrobinson using the blocker tracking app because: Broken package management usecases like config-manager doesn't work on upgrade usecases
Hi, when upgrading to dnf5, the python3-dnf package stays on the system and providing dnf4 command which you can use together with dnf-plugins-core providing e.g. the config-manager functionality. But you're right, it would be good to deliver the dnf5-plugins package for the dnf4 -> dnf5 upgrade path if dnf-plugins-core was present on the system.
DNF5 cannot simply replace DNF5's plugins with DNF4 ones because DNF5 does not yet replace DNF4. It only makes DNF5 default and users still can use DNF4 (via python3-dnf or dnf-3 commands) and therefore DNF4 plugins must be kept installable parallel to DNF5. Another issues is with different set of packages plugins for DNF5 and DNF4. Therefore the only option kept adding dependencies on DNF5 plugins (Requires or Recommends). Because we do not want force people to install unnecessary plugins, we cannot use hard dependenices. Thus we incline to adding Recommends (or conditional Requires) on the DNF5 plugins into DNF5 tool (with a condition on installed DNF4 plugins). The only drawback with Recommends is that weak dependencies are optional and people can have them disabled. Though, we consider the risk low as Fedora have weak dependencies enabled by default. This issue is about a default user experience. DNF team will decide on the exact implementation (which dependency to which package) in a week.
> DNF5 cannot simply replace DNF5's plugins with DNF4 ones because DNF5 does > not yet replace DNF4. It only makes DNF5 default and users still can use Seriously what are you talking about? It literally does it in the spec: https://src.fedoraproject.org/rpms/dnf5/blob/f41/f/dnf5.spec#_32 And if it leaves around the python bindings for software then the dnf5 package should have a requires to pull in the plugins so things actually work as documented in so many places. Leaving users with systems that are broken for some usecases isn't a great look!
(In reply to Peter Robinson from comment #4) > > DNF5 cannot simply replace DNF5's plugins with DNF4 ones because DNF5 does > > not yet replace DNF4. It only makes DNF5 default and users still can use > > Seriously what are you talking about? It literally does it in the spec: > https://src.fedoraproject.org/rpms/dnf5/blob/f41/f/dnf5.spec#_32 > DNF packaging is complicated. "dnf" package does not contain DNF4. It only contains /usr/bin/dnf symlink. > Leaving users with systems that are > broken for some usecases isn't a great look! I will emphasis SOME. DNF5 is NOT fully compatible replacement for DNF4.
Discussed during the 2024-09-09 blocker review meeting: [1] The decision to classify this bug as a RejectedBlocker (Beta) was made: "We agreed that the bug here is genuine and there ought to be a better effort made to achieve as close as possible as a 1:1 replacement of plugins on upgrade, but it does not violate the intent of the criterion. a sidebar discussion on the "plus any packages the user previously had" wording in the criterion footnote clarified that it is a leftover from the Edition work whose intent is not to make a bug like this a blocker, see meeting log for more details." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-09-09/f41-blocker-review.2024-09-09-16.01.log.html
This might be a good candidate for Common Issues documentation. Can anyone create a short summary of the most user-confusing bits? E.g. what dnf plugin-based commands stay present on upgraded systems (or even fresh F41 installs?), but no longer work as intended. Or any other issues or side-effects related to this?
I filed an upstream PR [1] to add `dnf5-plugins` as a weak dependency of `dnf5` when `dnf-plugins-core` is installed. The effect of this change is that for users with `dnf-plugins-core` installed, `dnf5-plugins` will automatically be installed when upgrading from Fedora 40 to Fedora 41 (unless the user disabled weak dependencies). So commands like `dnf builddep`, `dnf copr`, and `dnf config-manager` will still continue to work after upgrading to F41. However, many of the new DNF 5 plugins have substantially different interfaces compared to their DNF 4 counterparts. I think that will be a bigger source of confusion for users than missing plugins (at least after [1] is merged), since the most-used dnf4 plugins have already been implemented in DNF 5. For reference, here [2] is the upstream issue tracking progress of implementing the dnf-plugins-core plugins in DNF 5. > This might be a good candidate for Common Issues documentation. Can anyone create a short summary of the most user-confusing bits? E.g. what dnf plugin-based commands stay present on upgraded systems (or even fresh F41 installs?), but no longer work as intended. Or any other issues or side-effects related to this? I agree. We have a page in the DNF 5 docs [3] which documents changes from DNF 4 to DNF 5 and has some information about changes in plugins. I'm working to schedule a Fedora test day to test DNF 5 plugins, maybe we can use that to "stress test" our docs to see what's missing. To summarize the situation: - Many DNF plugins have a different command-line interface in DNF 5. Users should check [3] to learn about the differences. - (after [1] is merged) If dnf-plugins-core was previously installed, dnf5-plugins will be installed when upgrading to F41. - After upgrading to F41, the `dnf4` command (provided by `python3-dnf`) and DNF 4 plugins (provided by `dnf-plugins-core`) will still be present - On fresh F41 installs (and in the fedora:41 container image!), dnf5-plugins is installed by default. - On fresh F41 workstation installs, DNF 4 and dnf-plugins-core ARE installed by default (I just checked the F41 beta ISO). - In the fedora:41 container image, DNF 4 and dnf-plugins-core ARE NOT installed by default, but they can be installed. - Users can use DNF 4 plugins by calling the `dnf4` binary, as in `dnf4 reposync`. But doing certain operations with DNF 4 is not recommended if DNF 5 is also used on the system [4]. [1] https://github.com/rpm-software-management/dnf5/pull/1691 [2] https://github.com/rpm-software-management/dnf5/issues/389 [3] https://dnf5.readthedocs.io/en/stable/changes.html [4] https://fedoraproject.org/wiki/Changes/SwitchToDnf5#Different_system_state
Evan, any possibility a build will land soon? I was intending to collect karmas for the same during test week for DNF 5 Plugins
I can make a new upstream release, but F41 builds of DNF 5 are failing right now, they are blocked on an update to one of our dependencies [1]. Maybe I can create a side-tag with the updated dependency and a new build of DNF 5. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-9d8078d1e9.
toml11-devel is a header-only library. Adding fixed toml11 to a side tag, building dnf5, removing toml11 from the side tag and submitting the dnf5 build to Bodhi should be fine.
DNF 5.2.6.2 is now stable in Fedora 41 repos, so dnf5-plugins will automatically be installed when users upgrade to F41 (provided that they have dnf-plugins-core installed already, which will at least be everyone using `dnf4 system-upgrade`). I am closing this bug.