The changes sound very nice! I think
update should update it manually (like in apt)upgrade should upgrade the packages (like in apt)system-upgrade should use $releasever-$basearch, increment releasever and just workIf you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.
We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what youād like to express, please simply giving that post a 
instead of reiterating. You can even do this by email, by replying with the heart emoji or just ā+1ā. This will make long topics easier to follow.
Please note that this is an advisory āstraw pollā meant to gauge sentiment. It isnāt a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.
The auto-created poll is supposed to only reply to the first post in these topics. Turns out it is retroactive, too. Sorry about that ā Iāll delete these if they show up for any older discussions, but leave it for still open ones.
From the poll and the discussion, it seems that many people would be willing to try dnf5 with F40 already. Can we document a procedure for a one-time switch that migrates the metadata (installed fromā¦)? Would a dnf5 system-upgrade from F39 to F40 create that metadata, or would it need an additional migration step? Is something like that even possible (in F40) for people who donāt just use dnf? (but software center and the like)?
Hmm, I see. I certainly donāt want any users to be confused about such essential information. Weāre planning to review and complete this document in the following days, so weāll do our best to make it clearer.
Additionally, Iād like to include information about how the migration from dnf4 actually occurs: what parts are done automatically, if there are any manual steps users need to take to preserve existing configurations or system state, what precautions to take, what is not supported, etc. I see this as important, since Iāve already noticed several concerns regarding this both here and on other forums.
Hi Michael,
Thanks for your interest! 
You can already try dnf5 in parallel with dnf, even in Fedora 39; itās available in the official repository.
Regarding migrating metadata, we aim to cover that in the documentation mentioned in the previous comment. For now, I can say that dnf5 attempts to migrate the system state when used for the first time after installation. However, itās important not to mix installing packages using dnf4 and dnf5 afterwards, if you wish to preserve accurate information about package dependencies and reasons. This is because each tool uses a different format for this metadata.
As for system-upgrade, itās already implemented in dnf5, but extensive testing is still required. I wouldnāt recommend using it for upgrading your daily workstation just yet! Itās expected to be fully ready in Fedora 41 and utilized for upgrading from Fedora 41 to Fedora 42.
Sure, dnf5 is available, and Iāve used and tested it before (--assume-no). That might be part of the problem since you mention āmigration on first installā.
Turning this around: Is uninstalling dnf5 sufficient so that installing it again is a āfirst installā?
In any case, you seem to suggest shying away from dnf5 for system-upgrade even for F40->F41, and that means I shouldnāt even migrate F40 metadata to dnf5. I guess Iāll have to wait half a year then,
And if youāre interested in trying out dnf5 as the default package manager, you can try the dnf5-testing copr repository, which is also mentioned in the proposal.
I have been using dnf5 in testing since, oh the original request for testing went out. I find it seems faster than dnf4.
Turning this around: Is uninstalling
dnf5sufficient so that installing it again is a āfirst installā?
The data generated during the use of dnf5 is retained. Therefore, youāll need to manually delete the directory containing the created system state in /usr/lib/sysimage/libdnf5/, and then install and use dnf5 again.
you seem to suggest shying away from
dnf5forsystem-upgradeeven for F40->F41
Now, our next goal is to switch to dnf5 as the default in Rawhide, where the system-upgrade feature is not relevant due to its rolling-update nature. The official method for upgrading from Fedora 40 to 41 will still involve using the system-upgrade plugin from dnf4.
So yes, if you value preserving all information about existing package reasons and their source repository origins, and if you want to have greater confidence in a smooth transition to the next release, Iād recommend postponing the switch to dnf5 on your daily workstation with the Fedora 41 stable release.
Do we have any good basic C++ examples for how to interact with the libdnf5 API so that I can look at writing a PackageKit backend?
Hi Neal,
Iād say the really basic examples are in the tutorial section of our docs. Here is also the API reference documentation, though some parts are still missing.
Another thing Iād suggest is looking into the existing dnf5 modules in projects dependent on dnf, like Lorax or Ansible. While these projects use Python bindings, they essentially wrap around the C++ code, so the usage would be pretty much the same.
Lastly, for the use cases matching the dnf5 CLI, you can examine the implementation of the dnf5 commands, as they are the primary users of the libdnf5 C++ API.
This change has now been accepted by FESCo for Fedora Linux 41. This change can be tracked through tracker bug #2274820. A full set of the accepted changes can be found on the change set page.
This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.
To find out more about how our changes policy works, please visit our docs site.
Note that weāve found that DNF5 does not yet have a debuginfo-install plugin which is needed for plasma-drkonqi (KDE/Kinoite) but also likely useful for other projects.
See:
Itās also commonly used by users. Not having debuginfo-install command would be a significant regression. Debuginfod is a solution, but it only works in some circumstances, certainly not all. And calls to debuginfo-install are documented in a bazillion places, so even if some cases where a different solution could be used, used would still stumble if the command is not available.
I donāt claim to understand everything, but the āScopeā part seems to contradict itself - or there is some typo in there.
First it states:
and then further down:
Ack guys, thanks for the feedback. I see there is quite a demand for this plugin, and it shouldnāt be too complex to implement. I am adding it to the Fedora 41 plan.
Hi, this means that for Fedora 41 Rawhide users, the plugin might not be completely ready initially, but it will be completed and tested for the Fedora 41 stable release.