Best GUI for pacman?

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.


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.

1 Like

i use tkpacman from the aur,

vpacman looks like the old pacmanxg that is death can be qouirky in times

has issues if you have 3rd repos on the keys…

both are in TK but tkpacman runs pretty stable, it uses pacman directly no libalpm dbus whatever mixed in.

pacman neutral :slight_smile:

1 Like

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

Pamac-Aur is not an alternative? He’s doing his job right at me.

1 Like

Best gui for pacman is not pamac lol does not use directly pacman gona be more a pacman replacement for manjaro in the future

needs: packagekit-qt5 installed to use archpackages

1 Like

I removed pamac, snap, and flatpack from my Manjaro install. Using only pacman, yay and octopi (well trizen too as an octopi aur helper).

tkpacman is ok. Very ugly and pretty unintuitive, but gets the job done. Seems to work better on GNOME than on KDE.

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.

1 Like

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.


For general package info also for aur pkgbrowser. Further beside pacman and yay im using also pkgfile if see some lib issue have to peak which package

Pamac is what I have using just to get info on apps. I do recommend using pacman and yay.

one a sideline , pamac is not a gui for pacman :slight_smile:

1 Like

well, both are front-ends to libalpm as I understand it…

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

Actually, that isn’t the case. The pamac cli was developed long after the GUI. The GUI doesn’t call or use the CLI interface.

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?

1 Like

statement is true.

because octopi is also close to manjaro development they followed the path of libalmp also… before it was pacman straight on.

and pamac cli came…; bu further future only tell… i can tell pacman is in manjaro a part of pacman-contrib… in arch naturally different offcourse.

before they used pyalmp because pamac was based of python, but they got issues with the pyalmp developers :slight_smile:

1 Like