Hey y’all! What do you think is the best GUI option for pamac? I know it’s not “the Linux way” to do things with the GUI, but I’m a person that really likes to click buttons and see things happen that way.
I just deleted pamac, cause I couldn’t update my system with it. I used yay/pacman to do updates and I think it worked. I’d really like to have an app that I can use to update my system, preferrably one that works reliably and has Aur too.
KDE has Discover, but it doesn’t work for me. It just says “Sorry, no application back-ends found. Please report to your distribution.” It’s also really buggy and nonresponsive.
Hi,
there’s Octopi in the AUR and it’s written in QT so it should fit well in KDE.
I read different opinions about it, some like it, some not and I didn’t use it for some time so I can’t tell how good it works with the current pacman.
octopi was btw design before in 0.8?n as on pacman but late versions follow the path of libalpm like pamac does so on that point i dont know if it updated on that one
I use mostly yay and pacman but i also use pamac for some things and don’t have an issue with it. Yes, it has seen some issues but for the most part i have used it or the git or classic versions. As long as concurrent downloads are set to zero it works fine for me.
@ricklinux
Same here, pacman and yay for real package management, and pamac-aur-git as a quite nice GUI for getting info about packages.
There have been quite many biggish problems with pamac over the years, but currently it seems to work reasonably well.
The only issue I have with pamac is that sometimes it just stalls for a while (from seconds to about a minute). But after that it continues like nothing happened. Strange, seems like garbage collecting happens surprisingly often, but don’t really know why it stalls.
yes thats true. but pamac (gui) is a frontend of pamac (cli). sure both use libalpm offcourse, but does not make a frontend of pacman.
because pacman is a frontend of libalmp
pamac and pamac cli is both frontend… but just want to say , basicly its not a pacman frontend more not. because its manjaro’s package manager. and in future you must pacman install because its basicly already splitted at manjaro
I guess it depends what we consider “pacman”. At some point in the past, the pacman developers decided to split most of the logic into libalpm. Does that really mean that libalpm isn’t part of pacman? I struggle with not calling libalmpn part of pacman because most of what we think of as pacman has been moved into libalpm. If you look at the current source code for the pacman binary, it actually does very little except io and calls to libalpm. If the pacman binary is the only thing we are calling “pacman” then is yay no longer a pacman wrapper since it also uses libalpm directly?
It is true that Manjaro has discussed the possibility of splitting the pacman package so the pacman binary can be excluded but that conversation has been going on for over a year and pamac still depends on pacman and not libalpm. Even if they did that, the difference between being a front-end to pacman or libalpm isn’t a very interesting distinction since all the package management logic is in libalpm.
The statement “pamac is a front-end for libalpm, not pacman” is completely accurate. I just think it downplays that fact that libalpm is the core of pacman. Further, octopi, yay and others also use libalpm. If you are writing an application, why would you not want to interface with a library instead of parsing the results from a cli tool?
