F44 Change Proposal: PackageKit-DNF5 [SystemWide]

Project Discussion Change Proposals
, ,
1

PackageKit-DNF5

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Switch PackageKit to the new DNF5 backend built on libdnf5.

Owner :open_book:

Detailed Description :open_book:

As part of the ongoing work to replace the legacy DNF implementation with DNF version 5 ([[Changes/BuildWithDNF5|with builds in Fedora Linux 40]] and [[Changes/SwitchToDnf5|system tooling in Fedora Linux 41]]), this Change will switch PackageKit over to the new DNF5 backend built on the libdnf5 library.

Feedback :open_book:

Benefit to Fedora :open_book:

This unifies all user-facing package management interfaces with the DNF5 package management stack, which means that DNF5 features are now available regardless of how software management is done (such as via CLI, Cockpit, or software centers like Plasma Discover or GNOME Software).

Users should see a more reliable experience with PackageKit-based frontends, including more consistent behavior for system upgrades and better exposure of update information through the PackageKit API.

Scope :open_book:

  • Proposal owners: Merge [ Making sure you're not a bot! the pull request] for {{package|PackageKit}} to switch DNF backend implementations
  • Other developers: N/A (not needed for this Change)
  • Release engineering: [ Making sure you're not a bot! #13147]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: N/A

Upgrade/compatibility impact :open_book:

Users will be automatically migrated from the DNF4 backend to the DNF5 backend upon upgrade. There will be no manual configuration required to adapt to this change.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

Users should be able to test in Fedora 43 and Rawhide now easily by doing the following:

  1. Install the PackageKit-backend-dnf5 package
  2. Restart packagekit.service
  3. Use various PackageKit frontends (pkgctl, Cockpit, Plasma Discover, GNOME Software)

After this Change is implemented, merely being on Rawhide would be sufficient to test with normal operations with PackageKit frontends.

User Experience :open_book:

There should not be any user-visible changes beyond some minor differences in dependency resolution. Users are not expected to significantly notice any differences.

Dependencies :open_book:

N/A.

Contingency Plan :open_book:

  • Contingency mechanism: Revert to F43 configuration, where DNF4 is the default and defer to the next release.
  • Contingency deadline: Beta Freeze
  • Blocks release? Yes.

Documentation :open_book:

The standard DNF5 documentation applies here, as PackageKit merely consumes package manager configuration through libdnf5.

Release Notes :open_book:

PackageKit has been updated to use DNF version 5 for software management. This offers a more uniform and reliable software management experience across the various software management frontends (such as Cockpit, Plasma Discover, and GNOME Software).

Last edited by @ngompa 2026-01-05T22:01:35Z

Last edited by @ngompa 2026-01-05T22:01:35Z

2 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If 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 give that post a :heart: 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.

2 Likes
3

Thanks for getting this done!

1 Like
4

I would add that this actually significantly improves the user experience in scenarios where there is mixed usage between the the GUI package managers and the dnf command line.

Currently when you are installing packages or updates in a GUI package manager, it isn’t possible to roll back or even list those in dnf, because they are only in dnf4’s transaction database, which trips up users all the time (just check the community Discord and/or Matrix rooms).

For the same reason this also solves the problem of <unknown> package sources (From repository line in dnf5) and therefore also directly handling of the autoremove command. Because for packages installed through the dnf4 backend, dnf5 doesn’t know how or for what reason a given package/dependency was installed.

Also took me a minute to find where this backend is coming from, since my most recent info was that there isn’t one, but I guess this explains it

2 Likes
5

Hello everyone.
Across my three Fedora 43 Workstation installations, I currently handle updates and installs using dnf --offline and dnf offline-reboot, with PackageKit and GNOME Software disabled.
However, I believe the implementation of packagekit-dnf5 is a very useful and seamless addition for those who rely on PackageKit.
Best regards!

6

Same story for packages installed from the “PackageKit-command-not-found” plugin (the thing in the shell which gives you prompts like “Command not found. Install package ‘foobar’ to provide command ‘foo’? [N/y]”). Those currently appear in dnf4 history but not in dnf history.

2 Likes
7

Point of information.

Can we groundtruth the impact statement. I think there’s ongoing work to introduce dnf05daemon as a replacement for packagetkit in some of the listed software.

ref: https://fedoraproject.org/wiki/Changes/SwitchToDnf5#Background_service_support

I don’t think this invalidates the need for this change, but I just want to make sure we have an accurate understanding of which pieces of software are already planning on transitioning to dnf05daemon in the F44 timeframe and which will still be using PackagetKit as an abstraction layer.

1 Like
8

It is not a replacement for PackageKit. They aren’t fungible and serve different purposes. They have a completely different API and have different security domains.

As far as I know, GNOME Software is in a conflicted state upstream about whether dnf5daemon support will be added, but PackageKit remains supported and is expected to be the preferred option by upstream. Plasma Discover isn’t going to support dnf5daemon. I don’t know anything about Cockpit.

Some background history: dnf5daemon was intended to be the successor for dnfdaemon (originally developed by Tim Lauridsen and maintained by Angelo Naselli and I as part of ManaTools) for DNFDragora and also moved from ManaTools to the core DNF5 project for Anaconda (as their original plan was to move all backend stuff to separate services). This necessitated a more low-level API than what PackageKit provided.

However, fast forward to now and Anaconda went another direction where Anaconda itself is a background service to the web UI, and so it didn’t wind up using dnf5daemon. DNFDragora does still use dnf5daemon, but the port is incomplete due to numerous problems with the daemon itself. I’m not sure what we’re going to do there… :face_with_bags_under_eyes:

GNOME Software has a local patch by Milan Crha for dnf5daemon support, which was attempted in F43 and was reverted due to unresolvable issues (though it remains active on Rawhide). From an upstream perspective, only PackageKit is currently supported.

For all intents and purposes, don’t consider dnf5daemon and PackageKit in the same field of concern.

3 Likes
9

Correct yes, I never use it so it slipped my mind.

10

The PackageKit-backend-dnf5 is in Fedora 43 too. Does installing that make Kde Discover go to using dnf5 instead of dnf4 or does there need to be another custom package just for Discover to get it working with dnf5? I fired up Discover after installing PackageKit-backend-dnf5 and didn’t see any change or evidence of it in Discover.
So I’m guessing there has to be a specific dnf5 adaptor package for Discover.

11

Once PackageKit-backend-dnf5 is installed, it should automatically switch once you restart packagekit.service. You will be able to confirm this with pkgctl backend.

1 Like
12

pkcon backend-details shows

Name:           dnf5
Description:    DNF5 package manager backend
Author: Neal Gompa <neal@gompa.dev>

and so does
pkgctl backend

Status:
Backend: dnf5
Description: DNF5 package manager backend
Author: Neal Gompa <neal@gompa.dev>

Roles: cancel;depends-on;get-details;get-files;get-packages;get-repo-list;required-by;get-update-detail;get-updates;install-files;install-packages;
refresh-cache;remove-packages;repo-enable;repo-set-data;resolve;search-details;search-file;search-name;update-packages;what-provides;download-packa
ges;get-old-transactions;repair-system;get-details-local;get-files-local;repo-remove;upgrade-system

But my question is, does that mean plasma-discover will also get dnf5 backend support by installing "PackageKit-backend-dnf5? When I run the Discover GUI nothing shows dnf5 is in use. I can wait for a package upgrade to come along and just upgrade it in discover and look in the dnf5 command “dnf history list last” to have it in the listing, that would be a roundabout way to confirm it.

13

Thank you for working on the PackageKit DNF5 backend, Neal. I am fully in favor of using this in Fedora so that PK is no longer dependent on the DNF 4 stack.

But I do think the scope of this change proposal should be clarified. Is this the appropriate place to decide whether GNOME Software should use PackageKit, now with your new dnf5 backend, or use Milan’s dnf5daemon plugin as is the status quo in Rawhide?

GNOME Software has a local patch by Milan Crha for dnf5daemon support, which was attempted in F43 and was reverted due to unresolvable issues (though it remains active on Rawhide).

I wouldn’t characterize the issues with the dnf5daemon plugin as unresolvable. As far as I know, the current blockers are

From an upstream perspective, only PackageKit is currently supported.

True, for now.

For all intents and purposes, don’t consider dnf5daemon and PackageKit in the same field of concern.

Well, the dnf5daemon backend for GNOME Software exists, so for this purpose they are certainly similar.

There is a strong case for GNOME Software using PackageKit+this DNF5 backend in Fedora. But we shouldn’t necessarily rule out GNOME Software+dnf5daemon as I think there are still concerns about the maintenance of PackageKit long-term.

1 Like
14

Yes, it automatically uses it. You can observe this by installing an application and seeing it show up in the history for dnf5.

1 Like
15

I am making no judgement on whether GNOME Software does something one way or another. This Change can be tested on F43+, so GNOME Software is fair game to mention.

1 Like
16

The maintenance situation for PackageKit upstream has been in much better shape over the past year as Matthias Klumpp and I have figured out how we want to proceed for it (we discussed it at FOSDEM last year and started working on it in July). The maintenance situation for PackageKit in Fedora was in bad shape before I took over the package, because the previous maintainers weren’t around much. That situation is now resolved as well.

2 Likes
17

Uhm.. from a client software perspective they are either going to use one or the other not both as a way to interface with dnf and manage rpm package tasks. I’m not implying one is a drop in replacement for the other. I just want to know what the plans are for each of the pieces of software enumerated by name in the impact section of this proposal.

The impact section of this proposal appears to assume packagekit will continue to be used by all the enumerated software…which on my naive reading is in conflict with already accepted proposal from the f41 timeframe which states that work to switch some of the user face software to use dnf05daemon is happening and a switch for some of this software is anticipated.

So I want to make sure that the proposal here isn’t in conflict with the previous planning and that the impact statement as written isn’t intended to commit software that is currently using packagekit from continuing to make the the transition to dnf05daemon on the timescales that makes sense for them to do so. I don’t want acceptance of this proposal to be misconstrued as an override on previous decision making because of the named enumeration.

If the wording of the impact was something like ‘for software clients using PackageKit…’ without enumerating them by name I wouldn’t be as concerned. But as written there is an implication that may be read into that enumeration of software that this proposal commits those pieces to using packagekit, potentially overriding previous discussion in the scope of the the decision making and collaboration in the f41 change proposal.

So I just want clarity on what the plans are for these things. Or at the very least a note indicating that this change is not intended to read on decisions to transitioning to dnf05daemon.

18

I think I understand what you’re saying, but I don’t quite understand why.

Upgrading the PackageKit backend has no impact on downstream software’s efforts to replace (or not replace) PackageKit.
The interface for them remains PackageKit, they don’t need to care - nor should they - about what DNF version (or in fact any underlying package manager) is being used. That’s the whole idea of PackageKit, no? The abstraction of the enduser software away from the underlying package manager, i.e. DNF.

In other words: Downstream software can choose to work on a replacement of PackageKit, or choose not to. Neither has any bearing on each other.

19

Yeah, this is reading more into it than is necessary. I list the clients because otherwise nobody knows what they can test it with and what it can affect.

It would be silly for me to do otherwise, because PackageKit by itself isn’t useful to most people. It’s mainly useful for most people in the context of being used with a frontend interface.

But also, no promise about how GNOME Software gets to DNF5 has been made (not even in the F41 Change). Only an indication that work would be done on it. :man_shrugging:

Honestly, if the backend was going to change, I would expect an explicit Change document for it, like what I’m doing for PackageKit. I assumed one existed for the attempt for F43, but upon looking for it, I can’t find one.

20

thanks for the clarification.