Cant update packages with pamac

[nikgnomic]

@Nachlese

Use of the AUR package managers/AUR helpers is at your own risk

that includes pamac’s capability to deal with the AUR

If you enable the use of AUR in the pamac-GUI, it is that much easier to mix things up.

Some users could probably mix thiings up using pamac CLI (or downloading and building AUR package locally) that would not have any warning. but those users may be able to resolve issues from terminal response or copy/paste data in text format

But the better way to really mix things up is to install 2 or more AUR helpers

Recent topics about 3rd party AUR helpers show similar errors with pacman version for users on Stable branch

Any AUR helper should notify user if a repository package is being updated to an unsupported AUR package

[Nachlese]

@nikgnomic

Any AUR helper should notify user if a repository package is being updated to an unsupported AUR package

… as if that would help
(someone who doesn’t know what it means and more often than not doesn’t read or care)
/sarcasm
But yes - it would be good.
I’m pretty sure any AUR helper will list what is about to be done - with package versions and where these originate from.
But just “pretty sure” - can’t remember from last time I used yay or even pamac.

Personally: I usually go here

https://aur.archlinux.org/

and read about the package, look at the PKGBUILD and at the dependencies
and after having made the decision, I use either makepkg or some AUR helper

[soundofthunder]

@Nachlese

can’t remember from last time I used

Aside:- I use pamac-manager occasionally; to quickly remind myself of a package name, or package availability; then instinctively return to pacman to do the deed. I know many sing the praises of using a GUI application manager, but I’m not one of them; I’ve seen how easily they can fail to please.

[Jakus]

I can see whether its an Official Repository or AUR in a pamac download manager. I think I will still download some AUR packages, but only if I really need them. This case showed me how problematic it can become.

[Jakus]

So its preferable to download with pacman through the terminal?

[Nachlese]

@Jakus

So its preferable to download with pacman through the terminal?

That is just his preference - and mine as well.

The GUI is only used as a search tool, not to actually install stuff, even though one could do it from there.

@Jakus

I think I will still download some AUR packages

It might be just the wording, but I think it rather reflects your misunderstanding of what the AUR is and what you actually do when you “download some AUR packages”.

You “download” recipes. (called PKGBUILD)
In many or even most cases, these are used to fetch source code of an application or library
and then the application is compiled (built) on your own machine.
That is the reason why it may take a long time to install such package.

Through frequent updates of the base system (from the “official”) repositories,
the basis these self built applications rely on changes.
That is why some of them have to be re-built from time to time - even if their version did not change.

It is not hugely complex, but it is important to understand the consequences of what happens in the background when you decide to use something from AUR.

[soundofthunder]

@Jakus

So its preferable to download with pacman through the terminal?

As @Nachlese interpreted, surprisingly quite well:

@Nachlese

That is just his preference - and mine as well.

The GUI is only used as a search tool, not to actually install stuff, even though one could do it from there.

It is indeed my preference. I don’t mean to belittle pamac, as it’s potentially a useful tool. However, I do note that there have been issues with it, and inconsistencies with the GUI. This much becomes obvious to those who actually read forum posts regularly. pamac-manager is actively developed, so it’s only a question of time before it becomes generally more reliable.

I prefer pacman for updates and general use. It’s only when I specifically need to use a foreign package (from the AUR, or maybe an .appImage) that I might consider using pamac; and even then, I’d choose the CLI rather than GUI.

There are options such as appimage, flatpak, and snap, but frankly, one never knows how suited these might actually be for Manjaro, despite all the hype and smoke-blowing in the ecosystem to promote them.

While naturally nothing can be guaranteed, using the curated packages from the official Manjaro repositories gives the better likelihood of compatibility with Manjaro. My first choice is always a package from the official Manjaro repositories, installed via pacman.

Cheers.

@Nachlese

It is not hugely complex, but it is important to understand the consequences of what happens in the background when you decide to use something from AUR.

Just adding to this; something many (newer) users continue to ignore; use of the AUR is unsupported on Manjaro - if you break it, you fix it - though a kind member might sometimes point you in the right direction.

[nikgnomic]

Pamac is developed by Manjaro so any issue should be reported to this forum, preferably with meaningful data that Manjaro Team can use if needed

Recent posts from users on stable branch suggest that error in OP - ‘libalpm.so=13-64’ required by libpamac Is more likely to be from using a 3rd party AUR helper

[soundofthunder]

@nikgnomic

Recent posts from users on stable branch suggest that error in OP - ‘libalpm.so=13-64’ required by libpamac Is more likely to be from using a 3rd party AUR helper

And this was the case in a recent thread where the user had installed yay-bin (via the AUR) which listed later pacman (and presumedly the libalpm) versions as dependencies, which were [then] only available in either Unstable or Testing.