Default package manager, graphical side vs. CLI one

I am not sure if my findings are right, it’s however what one can observe on the Manjaro 23.1 setup sample here.

On graphical side the Add/Remove Software app gets installed on default. It seems to be based on pamac tool.
Regarding CLI-side: Add/Remove Software doesn’t offer the option of pacman package removal. I conclude from this pacman was mandatory package.

Do pacman and pamac use locally common packages database? From DEB-based distributions I learned the opposite: two more or less independent package managers use own database each. In my own judgement the chance is good for the same to apply in case of pamac and pacman too. However had no free resources to dig in. Should it be the case it would mean a discrepancy:
why on CLI-level different package management system than graphic environment level.

Can you translate that, so we can understand? You can’t remove pacman.

The default GUI package manager is pamac, which is developed by and for Manjaro. It comprises a command-line variant (pamac-cli) and two GUI versions which are functionally identical, but one of them (pamac-gtk) is based upon the gtk4 GUI toolkit and works best in gtk4 desktop environments (like GNOME), while the other one (pamac-gtk3) is based upon the slightly older gtk3 GUI toolkit and integrates better with non-gtk4 GUI environments.

Yes, because pacman — which is CLI-only — is the actual and official Arch package manager.

pamac was developed by and for Manjaro as a more encompassing alternative to pacman, because pamac also offers access to the AUR, and can be used for installing Snaps and FlatPaks, while pacman only accesses the official Manjaro repositories.

They both use the ALPM (“Arch Linux Package Management”) database, but pamac also has a local cache of the AUR repository — which itself only contains build scripts — and it can install and remove Snaps and FlatPaks, as mentioned above.

pamac does however have issues, and for installing reposiroy packages, you are always better off with pacman.

In addition to that, you can also install octopi, which is a GUI front-end to pacman, and which can also access the AUR if configured as such — it needs an AUR helper program for that, but yay is installed by default, and octopi can use that.

Either way, pamac and pacman use the same ALPM database.

1 Like

Add/Remove Software app must have a good reason to disable the option of pacman package removal - as for Manjaro here pacman entry Remove button is grayed out in Add/Remove Software.
One good reason possible (among all possible ones): the package to had been declared by distribution maintainers as mandatory one,

pacman is mandatory, yes. And it’s more reliable than pamac, which regularly has issues.

1 Like

In other threat I get informed “That is one of the reasons AUR and custom scripts is generally unsupported.”
I don’t see then the need (pamac buggieness you kindly mentioned previously) to stick on that tightly on pamac any more. Why not to follow then one single trail only, the top to bottom (GUI to CLI) and keep the system simple. less risk of misunderstandings ?

It is yet worse, the pamac GUI tool pushes apparently Wyland in Manjaro 23.1 which still isn’t the default display server - a loss on simplicity.

yes - they do.

pacman is a core package - and a lot of other packages depends on it.

pacman uses it’s own backend library - libalpm - which also serves the purpose of providing package management functions to other applications - this include pamac which is the Add/Remove Software tool.

Because pamac relies on libalpm for core package management - you cannot remove pacman as this would remove the libalpm on which pamac depends.

pacman does not support building custom scripts directly but it does support installing packages build using a custom script and as such it also supports removing them.

Another GUI package manager is Octopi also relying on pacman and libalpm.


Sorry??? I was talking about pamac.

However pamac-based GUI tool seems to be default one graphical env. level. In my feeling some lack of consistency.


Someone doesn’t “see it offering any other significant advantages over pamac or pacman, and its development goes slowly.” (state Dec. '23). Feedback given here in forum supports that opinion. Hence Octopi doesn’t attract me. I wonder which rationale proposal not really working :-1:

What are you even talking about? What do you want? Your english is like reading chinese. You can remove pamac if you want.

1 Like

A solid cli tool for the repo, and 2 different gui tools covering aur in different ways in case of bug in one of them, should really cover all usage scenarios, i think.


This is the primary resource for researching software


This is a GUI which is primarily useful for searching packages and finding results from all available sources - Repositories, AUR, Flatpak, and even Snapd if you want.


Eternally the favourite tool for package management with most of the more experienced users.

  • pacman is the main tool, though it is less intuitive and less 'user-friendly.
  • yay is the most used wrapper I believe, and has the benefit of using Pacman flags (yay -S = pacman -S ) and will call for password when required.

You can get away with using yay instead of pacman for most tasks.

At this stage, for installing software, a ‘software centre’ shouldn’t be required. Flatpak isn’t too hard to use from the terminal, but remains separate.

I discussed this with ‘yay’ developer who did consider the possiblity of offering some kind of ‘plugin’ system to add Flatpak/Snap etc. in the future.


‘a solid cli tool for the repo, and 2 different gui tools covering aur… should cover all usage scenarios’.

Topgrade is a nice tool to offer updating ‘all usage scenarios’, but as far as GUI goes, pamac-manager is the only tool which will find flatpaks/snaps/AUR/Repo items with a single search.

There are other alternatives, Octopi is used by some, Bauh is used by others - though again, only for Repo+AUR.

Add/Remove (pamac-manager) is a default installation, you’re right. It’s a Manjaro application, but it’s not necessarily the best tool for all jobs.

The situation is, indeed, rather more complicated than people appreciate.

I would be very happy if you could clear all of these issues up, and produce your own distribution which avoids them - though many of the issues are upstream, and so they’re out of our hands.

With KDE, there’s the ‘default KDE application’ which is Discover - and this also runs into some issues of its own. They can’t be fixed by Manjaro… and you must remember that AUR is ‘at your own risk’ - it is not supported in Arch either.

Sometimes it is better to stop worrying about such issues, and simply finding our own path and (as long as we have backups and snapshots) not worry too much as we can roll back and avoid most problems which arise.

Manjaro, or certain team members anyways, have stated numerous times that they plan to replace pacman and ultimately ALPM (“Arch Linux Package Management”) altogether with pamac.

But as it sits now pamac still uses ALPM, and even uses pacmans log file (/var/log/pacman.log).

These are the only accepted package managers available.

Other wrappers may be practical with little to no issues, such as octopi and yay (both pacman wrappers).

Discover uses something called packagekit for package management which, along with other problems, is an inherent security risk and should not be used.
(Discover as a way to manage addons from, ex, is different and OK)