Hi,
I have a nvidia dnf versionlock to make sure the drivers don’t update to 590. This work as intended when doing dnf update, however Discover updates disregards this versionlock.
This may be because Discover is using the old version of dnf and not the new dnf5.
This is the case on Fedora 43 for example, which I think is due to be fixed on f44.
Which distro and version are you using?
I’m using Fedora 42 with KDE Plasma Version: 6.5.5 on Kernel 6.16.7-200 for Wayland.
While writing and testing I came to this final answer:
**Bug 2026184 - PackageKit does not respect `dnf versionlock`
”**https://github.com/PackageKit/PackageKit/issues/444”
Thank you,
Let’s try:
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf4 versionlock \*nvidia\*585\*
sudo dnf4 update –-refresh
sudo dnf-3 versionlock \*nvidia\*585\*
Package already locked in equivalent form: …
Seems dnf-3 is just a link to dnf4.
Discover still wants to update my nvidia drivers to version 590.
So i Duck it and
Duck a.i. says:
“KDE Discover does not use a specific version of DNF; instead, it relies on the DNF package manager installed on your system”
fedora discussions says:
“PackageKit backend for Discover is still on dnf3”
”Dnf-3 has been a link to dnf4 for many years.”
And then it hits:
Bug 2026184 - PackageKit does not respect `dnf versionlock` (from 2021)
Personally I use dnf to do updates and not Discover.
When dnf is used issues are easy to debug as there is output with enough info to allow for an understanding of what dnf is doing or failing to do.
I also favor dnf and compiling my kernel and all packages myself, but why have discover - updates then? (It’s not true. I have not the balls and knowhow to even attempt doing this.) 
But like you said, packagekit will get dnf5 backend at some point, with versionlock support.
It will have taken 6 years (ykne opened on Nov 23, 2020) to get to a fix. Hoera for Fedora 44. 
Why? For people that like GUIs and prefer to avoid the command line I think.
Personally I unistall Discover and PackageKit.
I feel you didn’t get my joke. 
^^ I personally like to edit/inject the electrons directly to my monitor’s pixels to bypass the cpu, firmware and buggy software. No electricity or debugging needed and you always see the result you wanted. 
@sema, there’s a big difference between effectively just saying a command in a shell, versus compiling software, etcetera. It’s not much of a reduction in abstraction:
#!/usr/bin/env sh
flatpak update
sudo dnf5 upgrade --refresh --offline
sudo dnf5 offline reboot
@barryascott, any idea of how to tell? [1]
I see that package kit has a dnf5 backend now.
@barryascott, yes, per my citation. However, that’s in source. Any idea how to tell whether Discover is actually utilising PK’s DNF5 backend, with the installed packageset?
Any idea how to tell whether Discover is actually utilising PK’s DNF5 backend
I’m not barryascott but I know the answer to this one since I was just dealing with this.
There’s no way I know of from inside of the Discover Gui itself, but from command line you can diagnose if the DNF5 backends are in use with two commands
pkgcli backend
pkcon backend-details
They seem a bit redundant since I don’t think you can have pkgcli but not pkcon or vis versa since both are in the PackageKit package (but I’m talking about Fedora’s case) so they refer to the same backend.
This is just a guess, but I suppose the discover gui doesn’t bother saying “dnf5 is in use” because there was only a short time where there was any ambiguity. On Fedora, Discover was only using dnf4 for most of its life and there was an optional package named “PackageKit-backend-dnf5” you could manually install to make it use dnf5 backend. But now on my Fedora 44 Beta, that optional package is gone and the dnf5 support is rolled into the PackageKit package. So now it’s dnf5 out of the box.
The outputs don’t really need explanation:
pkgcli backend
Status:
Backend: dnf5
Description: DNF5 package manager backend
Author: Neal Gompa <neal@gompa.dev>
Roles: cancel, depends-on, …..(long list of info about roles)
pkcon backend-details
Name: dnf5
Description: DNF5 package manager backend
Author: Neal Gompa <neal@gompa.dev>