When I switched from Ubuntu, I was confused to find that Manjaro has two built-in methods to install programs: one using pacman and the other using pamac. They even have similar names.
I’m specifically referring to pamac-cli, which seems like an attempt to attract Debian-based/RedHat audiences because of its similar syntax. So, we have pamac (the CLI version) which can do 1) install packages from Manjaro repositories and 2) install from AUR. Essentially, it’s the same thing, but it extends capabilities, which means it duplicates functionality. It immediately brings to mind the analogy with PowerShell and cmd.
The question is, why does Manjaro have two package managers by default and why hasn’t it removed pacman, since pamac offers the same functionality?
I am guessing that this was the intent somewhat, yes. But as you noted yourself, pamac covers more than just the Manjaro repositories, because it also offers access to the AUR, and it can be used for installing Snaps and FlatPaks.
I’m guessing that pamac was developed with the intent of broadening the scope of the package manager, given that Manjaro sought to attract more users — of the wrong kind, in my personal opinion, because Manjaro isn’t a suitable distribution for everyone, which is painfully manifest all over the forum.
Oh, believe me, someone who shall not be named but who is one of the Manjaro leaders has once had the not-so-brilliant idea of omitting pacman, but luckily, the wiser people among the community were able to dissuade him from that horrible idea.
The facts are that Manjaro is an Arch derivative, that it closely follows Arch’s decisions, that pacman is the Arch-standard and virtually perfect — i.e. without bugs — package manager, and that pamac is (still) a buggy mess.
Many of us either never use pamac or only use it for installing packages from the AUR. It is always recommended to use pacman unless you want to install something that isn’t in the official Manjaro repositories.
It is a toggle in the preferences. The bigger question is, is it really wise to enable it. At least do not check the automatic update feature for aur or flatpak, that can become a problem.
Manjaro might not be suitable for absolute beginners as it can attract some users that don’t realise Google actually exists and want to be spoonfed but unfortunately that happens on every distro.
I do think however manjaro is the most user friendly arch based distro and the best option for “beginners” who prefer a rolling release
You might appreciate this quick comparison between pacman and pamac;
these are some common commands:
Using PACMAN:
# Search for a package (official repositories):
pacman -Ss <packagename>
# Search for information about that package:
pacman -Si <packagename>
# See if you have a package installed already:
pacman -Qs <packagename>
# Find information about the local package:
pacman -Qi <packagename>
# Install the package (note the use of `sudo`):
sudo pacman -S <packagename>
# Perform an update:
sudo pacman -Syu
# Refresh package meta data:
sudo pacman -Sy
Using PAMAC:
# Build a package from AUR:
pamac build <packagename>
# Update and include AUR packages:
pamac update --aur
# Update without including AUR packages:
pamac update --no-aur
# Update everything (not my preference):
pamac update
Is it possible to install a flatpak package with this? How can we download for example flatpak krita via pamac? There is not a single example on the Internet where someone would download a flatpak via pamac-cli.
Looking at the man page the management of flatpaks does not seem to be an option in pamac-cli. If this feature is handy for you, log an issue here or contribute to the development.
Personally, I would rather be in favor of dropping FlatPaks and Snaps, because they violate the principle of UNIX, which is to integrate all applications into the operating system, so that they become part of it.
Snaps and FlatPaks embody the smartphone “app” mentality, they don’t integrate well with the operating system, they consume too much disk space, and they are maintained by third-parties rather than by either the Manjaro developers or the Arch developers upstream.
But alas, there is a demand for those things, so we have to offer access to them.
They are disabled by default which I think is the correct way to address it. But with handheld gaming devices now gaining momentum in Linux I think flatpaks are the safest option for those
The unnamed individual who once sought to drop pacman also intended to make Snaps the official package format for Manjaro at the same time. All that was then still required was for the distribution to change its name to Mabuntu, or Ubujaro, or something…
Luckily, said individual is amenable to feedback from his fellow Manjaruminati™, who are wise and just, and who only seek what’s best for all penguins.
I see it as a good thing, you have a second option to restore your system just in case when something went wrong.
What are you doing when your Desktop is crashing
and you can’t reach pamac GUI, TTY + Pacman saves the day.
I personal love GUI and just simple mouse clicks,
i evade Terminal when ever i can, but at the same time,
I don’t see CLI not as a enemy and to give a good example:
1,5 Month ago, the last big 2 month delayed KDE Plasma 6 Update which impacted a lot Manjaro User’s run into a mess who updated their System’s with Pamac GUI which also wanted to update himself and crashed himself to death.
This was one of the rare situation where we all pointed to use pacman CLI, log out from your Desktop/User Account to start TTY and update your whole system from there, which worked flawless for me.
All in all im happy that both exists and give us Manjaro user’s additional safety (pacman) or usability (pamac).
The golden rules — which will of course be missed again by 99% of all forum dwellers, simply because they’re only interested in their own threads, and thus they won’t be looking at this one — are…:
If you want to install a single package, or a small amount of packages, you can use pamac — or octopi, which I personally prefer, and which is more stable.
If there is a small amount of updates waiting — i.e. a couple of fast-tracked packages such as chromium, firefox, pamac, inxi et al — and there are no low-level system components being replaced, then you can use a graphical package manager.
If there is a bundled update — which always comes with a dedicated Announcements thread and which generally includes a newer kernel and other essential system components, log out of your GUI completely, switch over to a tty, and run the update with pacman. If you have any AUR packages installed, you can then update those after the bundled update via the pamac command line interface. And then you will have to reboot anyway.
Incorrect. The Internet is likely where the information came from while compiling a quick and dirty list of commands. Apologies for not proof-reading the content; that’s a common problem here.
Krita, as an example, is available from the extra repo. If a package is available in the official repo’s, this is the version one should use.
An opinionated comment, yes, but with good reason. Ask around.
@Aragorn (for one) can offer well-versed reasons not to use containerised apps, especially when a Manjaro-curated repo version already exists; in fact he already has, many times. Search a little.
we may also do that in octopi + yay or via octopi notifier…
anyway in manjaro we may remove many things after installation (pamac, plymouth etc.)
more sense to have octopi in plasma then pamac IMHO
That used to be the case, but then the pamac GUI was pushed back onto my system with an update after I had removed it, and then later the gtk4 version was pushed onto my system instead of the gtk3 version, and I had to explicitly replace it with the gtk3 version again.
pamac is considered a halo component of Manjaro. There was work underway at creating a qt-based variant, but the project lagged behind on the gtk variant and was ultimately abandoned.
So I do have the gtk3 variant of the pamac GUI installed here, but I never use it. If I want to look up on a package by way of a GUI, I’ll just use octopi.
