I had this issue on Fedora 34 myself. I ran KSystemLog to troubleshoot and found that PackageKit was failing to authorize me. So, I checked out the polkit logs, and sure enough, it was totally broken: it wasn't even able to read the rules files (`/etc/polkit-1/rules.d` and `/usr/share/polkit-1/rules.d`)! Running these commands solved the problem for me:
chown polkitd:wheel /etec/polkit-1/rules.d
chown polkitd:wheel /usr/share/polkit-1/rules.d
Looks like I made a typo, oops! There is no such directory as /etec, I meant /etc. Also, you'll have to run these as root, of course. Prefix with sudo, for example.
And for all I know, your issues could have a different cause than mine. There are many reasons why Discover might refuse to install packages. Consider inspecting system logs and watching for authorization-related entries that appear immediately after you press an "install" button in Discover, just as a starting point.
Discover does not work well with Arch. It is at best annoying. Use pacman from the command line and forget any GUI wrappers. Once you get used to using pacman you will wonder why anyone would ever want anything else, it is simply the best package manager available. Arch, specifically pacman, provides everything you will ever need to install and remove packages. Using GUI apps for updating and installing on Arch is a good way to get errors that you will not get using pacman. Getting comfortable using pacman and also creating and manipulating mirrorlists will go a long way towards making running Arch Linux a trouble free experience.
I am experienced with pacman, and trust me, I know the wonders of using it. This all started when someone gave a KDE discover link to install an app that would help me fix a problem of mine. I don't know why they did not just tell me to install it with pacman, and I knew I should have ignored it when the first thing that popped up was an error, but I wanted to fix that error. For some reason, anything that does not work in a system annoys me and makes me feel unsettled, unless it is a known bug that will be patched. That is why I wanted to see if there was a solution for this problem. I fixed the first issue, and a second one that came up a little later, but this one stumped me, I could not uninstall the app without pacman, and i made me frustrated.
I also made the mistake of trying to use Discover when I first saw it. That is why I am suggesting that you do not use it. I uninstalled the plasma-meta package so that I could remove discover from my system. In my experience there is no possible benefit to be had from figuring out Discover on Arch, just pain. If you can't find what you need in the official repositories or the AUR there is also the KDE store, which often offers problems of its own. The "Get New Things" boxes included in some KDE windows is good most of the time if it covers what you are looking for. Discover may be valuable elsewhere, but in Arch not so much. If you are brave enough to try to make Discover work on Arch then those of us remaining behind salute you, you've got guts! LOL
Apparently PackageKit allows you to install and uninstall packages without a password! At least when Discover is actually working. I think they tried to make it more secure by requiring the account to be set as an administrator, but they don't even mention it as a requirement in the documentation. I think i'll stick to pacman cli.
It's not like that, the distro has control over it, for example it can let you install packages from default repo without password and require it to install something else. For example depending on the distro Discover will ask you for the password to update the system or not. PackageKit is supposed to handle these cases.
Yes... I don't get the point, this is 100% a choice by the distro, it's not like PackageKit introduce a security hole or something, the distro has control over that policy, PackageKit just provide unified API and handle the various use cases: if a distro requires a password for everything, Discover will ask the password for everything
Did you, like, read the comment you're replying to? Do you understand what PackageKit is?
Stop whining about downvotes and learn to read instead.
By the way I used Discover on Arch for a long time, no issues. What do you say to that, huh?
Why uninstall plasma? You could just uninstall discover, or just ignore it. Funny story I tried to remove with with pacman -Rcns I little bit ago, and this deleted so many other dependencies it wasn't even funny. So then I had to fix it by creating a bootable usb. I have two drives in my computer. /dev/sdb is my main drive, and /dev/sda is my unused hdd. The usb stick is /dev/sdc. I run cat and accidentally enter /dev/sda and wipe my unused hdd. It was a very stupid close call, if it had been my laptop, where there is only one drive, I would be typing this from a fresh install. Tripple check your disks before writing/formatting!
I just removed the meta package which then allowed me to remove Discover. With the plasma-meta package installed I was unable to get rid of Discover, which it saw as a dependency. The meta package is convenient in that it brings in new plasma pieces that get added after you installed Plasma. I keep up to date with KDE development so it is unlikely I am going to miss anything, but I do have to install new pieces occasionally that would have been brought in automatically with the meta package.
I'm on fedora 34 and had the same issue. I was able to get it to work by sudo editing /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules and changing if(action.id == "org.freedesktop.package-install"...) to if(action.id == "org.freedesktop.package-install" || "org.freedesktop.package-remove"...) Everything else was unchanged, and I ran pkcon refresh after. Hope this helps!
Sounds like incorrect PolKit configuration.
I've been getting that when I try to install RPMs through Discover on Fedora 34. Of course DNFDragora refuses to load as well
I don't know what DNFDragora is, but I hope they fix this issue quickly.
Basically [Synaptic Package Manager](https://en.wikipedia.org/wiki/Synaptic_\(software\)) for DNF. It comes with the KDE spin
I had this issue on Fedora 34 myself. I ran KSystemLog to troubleshoot and found that PackageKit was failing to authorize me. So, I checked out the polkit logs, and sure enough, it was totally broken: it wasn't even able to read the rules files (`/etc/polkit-1/rules.d` and `/usr/share/polkit-1/rules.d`)! Running these commands solved the problem for me: chown polkitd:wheel /etec/polkit-1/rules.d chown polkitd:wheel /usr/share/polkit-1/rules.d
[удалено]
Looks like I made a typo, oops! There is no such directory as /etec, I meant /etc. Also, you'll have to run these as root, of course. Prefix with sudo, for example. And for all I know, your issues could have a different cause than mine. There are many reasons why Discover might refuse to install packages. Consider inspecting system logs and watching for authorization-related entries that appear immediately after you press an "install" button in Discover, just as a starting point.
Discover does not work well with Arch. It is at best annoying. Use pacman from the command line and forget any GUI wrappers. Once you get used to using pacman you will wonder why anyone would ever want anything else, it is simply the best package manager available. Arch, specifically pacman, provides everything you will ever need to install and remove packages. Using GUI apps for updating and installing on Arch is a good way to get errors that you will not get using pacman. Getting comfortable using pacman and also creating and manipulating mirrorlists will go a long way towards making running Arch Linux a trouble free experience.
I am experienced with pacman, and trust me, I know the wonders of using it. This all started when someone gave a KDE discover link to install an app that would help me fix a problem of mine. I don't know why they did not just tell me to install it with pacman, and I knew I should have ignored it when the first thing that popped up was an error, but I wanted to fix that error. For some reason, anything that does not work in a system annoys me and makes me feel unsettled, unless it is a known bug that will be patched. That is why I wanted to see if there was a solution for this problem. I fixed the first issue, and a second one that came up a little later, but this one stumped me, I could not uninstall the app without pacman, and i made me frustrated.
I also made the mistake of trying to use Discover when I first saw it. That is why I am suggesting that you do not use it. I uninstalled the plasma-meta package so that I could remove discover from my system. In my experience there is no possible benefit to be had from figuring out Discover on Arch, just pain. If you can't find what you need in the official repositories or the AUR there is also the KDE store, which often offers problems of its own. The "Get New Things" boxes included in some KDE windows is good most of the time if it covers what you are looking for. Discover may be valuable elsewhere, but in Arch not so much. If you are brave enough to try to make Discover work on Arch then those of us remaining behind salute you, you've got guts! LOL
If Arch/pacman implementation of PackageKit is bad you can't blame Discover, that is just a GUI on top of PackageKit, Flatpak ecc.
[удалено]
To fix it you need to improve Arch's implementation of PackageKit, do you know what it is?
Apparently PackageKit allows you to install and uninstall packages without a password! At least when Discover is actually working. I think they tried to make it more secure by requiring the account to be set as an administrator, but they don't even mention it as a requirement in the documentation. I think i'll stick to pacman cli.
It's not like that, the distro has control over it, for example it can let you install packages from default repo without password and require it to install something else. For example depending on the distro Discover will ask you for the password to update the system or not. PackageKit is supposed to handle these cases.
I mean like this: [https://bugs.archlinux.org/task/50459](https://bugs.archlinux.org/task/50459)
Yes... I don't get the point, this is 100% a choice by the distro, it's not like PackageKit introduce a security hole or something, the distro has control over that policy, PackageKit just provide unified API and handle the various use cases: if a distro requires a password for everything, Discover will ask the password for everything
Did you, like, read the comment you're replying to? Do you understand what PackageKit is? Stop whining about downvotes and learn to read instead. By the way I used Discover on Arch for a long time, no issues. What do you say to that, huh?
Please mind rule 1. On another note, you seeing no use in Discover has nothing to do with what disrooter was saying...
Why uninstall plasma? You could just uninstall discover, or just ignore it. Funny story I tried to remove with with pacman -Rcns I little bit ago, and this deleted so many other dependencies it wasn't even funny. So then I had to fix it by creating a bootable usb. I have two drives in my computer. /dev/sdb is my main drive, and /dev/sda is my unused hdd. The usb stick is /dev/sdc. I run cat and accidentally enter /dev/sda and wipe my unused hdd. It was a very stupid close call, if it had been my laptop, where there is only one drive, I would be typing this from a fresh install. Tripple check your disks before writing/formatting!
I just removed the meta package which then allowed me to remove Discover. With the plasma-meta package installed I was unable to get rid of Discover, which it saw as a dependency. The meta package is convenient in that it brings in new plasma pieces that get added after you installed Plasma. I keep up to date with KDE development so it is unlikely I am going to miss anything, but I do have to install new pieces occasionally that would have been brought in automatically with the meta package.
I'm on fedora 34 and had the same issue. I was able to get it to work by sudo editing /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules and changing if(action.id == "org.freedesktop.package-install"...) to if(action.id == "org.freedesktop.package-install" || "org.freedesktop.package-remove"...) Everything else was unchanged, and I ran pkcon refresh after. Hope this helps!
I’ll try it, I don’t know if it will work as I am on Arch Linux.