Bug 480525

Hi, Jan! Thanks for alerting the KDE team about upcoming changes to package manager in Fedora. As a bug triager I have marked the category as "wishlist" for a feature that is hoped will be implemented.

Thanks for reaching out. Does this mean that you don't plan to support PackageKit with DNF 5 at all? And that therefore it will need its own new backend, not unlike the rpm-ostree backend?

(In reply to Nate Graham from comment #2)
> Thanks for reaching out. Does this mean that you don't plan to support
> PackageKit with DNF 5 at all? And that therefore it will need its own new
> backend, not unlike the rpm-ostree backend?

Yes, the situation is that PackageKit has been in maintenance mode for some time now, and there are no plans to add new features or backends like DNF5. Therefore, a specific backend or plugin for the dnf5daemon integration will be necessary.

Thanks for the info.

I've long suspected that we'd see this kind of thing from distros to work around the limitations of PackageKit. It's a bit of a shame IMO, since PackageKit itself already needs custom backends for package management systems, so that work already has to be dome somewhere. And conceptually it seems like it would be best if the library itself were improved to support any use cases not yet covered. There are benefits to supporting PackageKit that go beyond Discover: we use it in other places too, for example to prompt the user to download needed Samba packages in the file sharing setup wizard, or to download Konsole if they open Dolphin's terminal panel without Konsole being installed. Not supporting PackageKit means those features will stop working in your distro. For the immutable distros this is understandable since the concept of traditional package management doesn't really apply there, but for a non-immutable distro, it's supportable in principle.

Still, it is what it is. As a path forward, I suggest doing what the Kinoite and SteamOS folks did: write your own custom backend for Discover and submit it to KDE for inclusion. Given your knowledge of how DNF5 works, I think you or your team (or an adjacent one?) represent the ideal folks to do the work!

(In reply to Nate Graham from comment #4)
> Thanks for the info.
> 
> I've long suspected that we'd see this kind of thing from distros to work
> around the limitations of PackageKit. It's a bit of a shame IMO, since
> PackageKit itself already needs custom backends for package management
> systems, so that work already has to be dome somewhere. And conceptually it
> seems like it would be best if the library itself were improved to support
> any use cases not yet covered. There are benefits to supporting PackageKit
> that go beyond Discover: we use it in other places too, for example to
> prompt the user to download needed Samba packages in the file sharing setup
> wizard, or to download Konsole if they open Dolphin's terminal panel without
> Konsole being installed. Not supporting PackageKit means those features will
> stop working in your distro. For the immutable distros this is
> understandable since the concept of traditional package management doesn't
> really apply there, but for a non-immutable distro, it's supportable in
> principle.
> 
> Still, it is what it is. As a path forward, I suggest doing what the Kinoite
> and SteamOS folks did: write your own custom backend for Discover and submit
> it to KDE for inclusion. Given your knowledge of how DNF5 works, I think you
> or your team (or an adjacent one?) represent the ideal folks to do the work!

Thank you too for sharing the background. I will discuss it with the team.

One more point to note is that, for now, PackageKit with the current dnf and the new dnf5 can coexist on the same system, at least on Fedora Linux. While not ideal due to differences in package states metadata formats stored at separate locations, resulting in inefficient storage usage, this is generally not noticeable for the typical GUI user. Additionally, the backing RPM DB remains the only shared source of information about installed packages.