It is not being abandoned. As the matter of fact, there were two updates to libpamac only last week — or at least, on the Stable branch.
In a UNIX system, most of the graphical utilities — I’m not talking of so-called productivity software and the likes — are actually only graphical front-ends to character-mode/command-line utilities, for two reasons…:
-
UNIX has to be fully usable even without its GUI running, because on UNIX, the GUI is optional; and…
-
It is more efficient, and makes it easier, to write graphical utilities that use command-line tools in the background than to reinvent the wheel.
pamac does live up to this design philosophy, but only partly. On the one hand, it is usable both as a command-line tool and as a graphical tool — and in both a gtk3 and a gtk4 version, even. On the other hand however, pamac works with the ALPM database, and is allegedly fully compatible with it, but it uses its own interpretation of ALPM, not the existing package manager of ALPM, which was designed specifically for ALPM by the ALPM developers.
Now, if you look at octopi for instance, then octopi doesn’t need to be compatible with ALPM, because octopi is merely a graphical front-end to the already existing and as-perfect-as-it-gets pacman, and to an AUR helper — it has a configuration section that allows you to choose which AUR helper.
Of course, what octopi does not support, is Snap and FlatPak. But as I said earlier, those are foreign package formats, and for all intents and purposes, that is third-party software, because Snaps and FlatPaks are intended to be distribution-agnostic.
Still, all things considered, pamac may get there at some point in the future, but considering its current quality level, the safest bet at having the least amount of problems with software installation/removal and system updates is to use pacman.
There is an additional factor involved here, which I have addressed in my HowTo on updating as safely as possible, which is that it is always best to update from a tty while completely logged out of the GUI, because while your GUI is running, more shared libraries are going to be in use, while the update process may be overwriting them, with as a result that if the GUI needs to load some code in memory from an already opened but only partly loaded shared library, strange things can and will happen.