I’m running Discover on EndeavourOS / Arch, and often when I click on an application to view its details page, I am met with an error like this: “skanpage;23.08.0-1;x86_64;extra: could not find or read package.” These errors don’t prevent me from installing the package or give me any other issues as far as I’m able to tell. Does anyone know why this might be happening?
I tried on my Arch system and got the same error. Installing worked (probably).
That being said I recommend that you don’t install Arch Repo packages using Discover.
Any reason you don’t use pacman instead?
I don’t know how EndeavourOS handles it but atleast Arch warns against it:
https://wiki.archlinux.org/title/Pacman/Tips_and_tricks#Graphical
1 Like
As does EndeavourOS - Does EndeavourOS allow GUI package installers? - Important notifications - EndeavourOS
1 Like
Yea, I’ve read the articles. The fact is that I just like using discover to, well, discover new packages, and while I’m there, I’ll install a thing or two. I probably use pacman most of the time, but I like having an ‘app store’ like experience.
That’s an excellent use of Discover in Arch and Arch based distros.
Here be dragons 
1 Like
I’d really like to understand more about the taboo of GUI package management on Arch & Arch based distros. There are two links in the Arch wiki page about why packagekit GUI frontends aren’t recommended:
- The first, from 2016, cites a security concern, but surely it’s the prerogative of the user to balance security and usability on their system.
- The second, from 2018, is just a complaint that a second package needs to be installed in order to get gnome-software working, with the comment “I don’t want to tempt people to install it. It only results in a big mess.”
Ignoring the first link, as that just seems to be a matter of choice, I’ve never heard an explanation detailing why using packagekit results in a “big mess.” I’ve been using it for a number of years now, and have yet to notice any issues.
I’m sure this can’t be the explanation, but from my perspective, it feels like elitism - that Arch attitude that you’re committing sin if your system doesn’t fly in the face of usability at every turn.
I am very seriously curious what the issues are here, because while everyone on the internet seems absolutely certain that you should under no circumstances employ a graphical package manager, I’ve never seen a detailed technical explanation for this opinion, and I would really like to understand the position!
If you have only been installing applications using packagekit GUI frontends (and not updating) it’s certainly possible that you won’t have noticed any issues. However, that doesn’t mean there haven’t been any issues.
Installing in a terminal using pacman will display information about any optional dependencies, and any changes to your system as a result of installation. For many applications these changes will be minor, or even non-existent. But by using Discover (or any other GUI frontend) you won’t know about them.
So installing applications with a packagekit GUI frontend is “not recommended, use at your own risk” as it says next to packagekit-qt5 here. If you feel that it’s a risk worth taking and know how to rescue your system, then carry on if you wish.
Updating/upgrading Arch Linux with a packagekit GUI frontend is a very bad idea, and will bite you hard in the posterior at some point.
1 Like
If you have only been installing applications using packagekit GUI frontends (and not updating) it’s certainly possible that you won’t have noticed any issues.
Ah, that’s interesting. I use Discover to update any Flatpaks and Plasmoids, but I always run yay first to knock out anything from the Endeavour repos & the AUR. I also restart after this, if it’s recommended.
So the issue is that Discover won’t alert you of any dependency conflicts, et cetera, and will just do whatever it takes to get the package installed, consequences be damned? How do other distros get away with it?
1 Like
This is purely a symptom of how Arch manages it’s PackageKit backend, other distributions are fine assuming that they deal with the consequeces and design decisions of PackageKit. For example, Fedora installs weak (optional) dependencies by default and I have no trouble using Discover to install and update packages through Discover 
4 Likes
I see. Makes me wish they’d give the matter some attention! I know it’s meant to be a DIY distro, but it would be nice if usability were a higher priority for those who want to make their install genuinely simple.
1 Like
You’re not inherently wrong at all to prefer a simpler interface to that functionality - but I imagine you’d find that such feedback would run counter to what the core maintainers believe Arch to be, based on the points here and here.
GUI configuration utilities are not officially provided, encouraging users to perform most system configuration from the shell and a text editor.
Whereas many GNU/Linux distributions attempt to be more user-friendly , Arch Linux has always been, and shall always remain user-centric . The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users
as possible.
I don’t use Arch, btw - but felt like it might be helpful to temper expectations of what folks contributing to Arch - or EndeavourOS, for that matter (a “terminal-centric distribution”) would prioritize.
1 Like
I understand what their philosophy is (I’ve read the wiki); I’m expressing that I wish it would change somewhat in favor of usability.
That isn’t going to happen with Arch.
I preferred to do package management in the terminal long before I used any Arch based distros - it showed me what was going on and gave me the opportunity to avoid dependencies that I did not want to install.
I’m not asking for GUI tools, I’m happy to install them myself if I want them, but compatibility with a fairly common thing like packagekit would be great.
There’s just so much outright hostility towards usability in the GNU/Linux sphere and it drives me up the wall. Of course, distro maintainers can do what they like; I’m neither a maintainer, nor a paying customer with any right to lodge a complaint, but I do like to have a good moan about the state of affairs in the hope that maybe I can help move public opinion.
But yea, I use the terminal plenty, I know the philosophy behind these distros, I’ve been through the Wikis. I just think some of these decisions could bear a bit more conversation.
The issue for Arch is that it enables a very wide range of choices and configurations. Most other distros stick with just one bootloader, kernel image generator etc etc, and can therefore build all packages and configuration files against those choices.
Because Arch enables the user to make different choices about so many elements of the system, it has to devolve some elements of package and system management to the user.
There are distros that prioritise out of the box usability. But Arch will always prioritise providing a wide range of options for users, which is sometimes at the expense of initial usability.
There are distros that prioritise out of the box usability. But Arch will always prioritise providing a wide range of options for users, which is sometimes at the expense of initial usability.
I’ve been using GNU/Linux for over ten years now, so I get this. I don’t have an issue with the ‘assembly required’ aspect of these distros. I suppose my frustration with PackageKit in particular (now that I’ve learned a little more about it) is: why have it in the repos at all if it is inherently incompatible with the system?
Surely, if they don’t want people using it, and if it’s practically guaranteed to break something, the Arch team oughtn’t have put it into the repos? Alternatively, in the case that it was voted in from the AUR, surely that would indicate that there is enough user interest to warrant proper support?
I use EndeavourOS because it’s a community distro, for its wide selection of available software, and for how quickly the packages are updated. I use my PC to get work done (mostly design work and web dev), so I spend quite a lot of time setting it up to make it as simple and efficient as possible so that I can work quickly. The idea that I can technically install a nice GUI software store on my system, but I had better only use it to look lest my system implode when I install something just makes me sad haha. I don’t expect a Pop!_OS experience from an Arch or EndeavourOS install, but I can’t help but feel as though I’m being hampered from making my system into a more usable one in this instance.
Perhaps Pacman and PackageKit are just inherently, irrevocably incompatible for reasons I don’t understand though, per:
The issue for Arch is that it enables a very wide range of choices and configurations. Most other distros stick with just one bootloader, kernel image generator etc etc, and can therefore build all packages and configuration files against those choices.
The fact is, I don’t have a clue how PackageKit works.
The basic problem is an incompatibility with what the package management system requires and what the PackageKit library provides: Arch requires that users make active decisions after deciding to install something, while PackageKit categorically does not support this.
And for what it’s worth, this problem isn’t limited to just Arch; openSUSE’s package manager is also quite chatty and asks the user to make decisions, and this causes similar issues with Discover there.
Someone will have to bend here, or else a new library that does support interactivity during package installation will have to be written, and then everything will have to be ported to use it.
3 Likes
I see. It seems like you’d have to vet packages very carefully as a distro maintainer to avoid dependency conflicts that would require a user decision - unless users could install multiple versions of the same library.
I suppose this is why Flatpak is becoming so popular?
Distro developers just need to implement their PackageKit plugins in such a manner that all optional dependencies get installed by default, and ambiguous situations are automatically resolved in the least destructive way. This isn’t a technical challenge; not doing it is a design decision.
I think Flatpak is becoming popular because it solves a different set of problems: ownership, update frequency, containerization, etc. However being able to determine with 100% reliability which dependencies the user will get when they install your app is another benefit, if not a primary one.
I understand what their philosophy is (I’ve read the wiki); I’m expressing that I wish it would change somewhat in favor of usability.
I sympathize, and I used to take this perspective myself, but the fact of the matter is that you’re wanting it to be something it’s not; you have to accept it for what it is. This is why DIY-ish distros like Arch and Debian that deliberately avoid offering a usable default experience get used as the basis for other distros that do care about usability, like SteamOS and Ubuntu.
If you find that you want a more usable OOTB experience, it might be a sign that Arch isn’t a good fit for you; the philosophical disagreement you have with what it is at its core will only grow and become more irritating over time. Better to find something that suits your tastes IMO. Or, you can accept it for what it is and stop hoping it will change into something else.
2 Likes