I ran into some problems after the latest upgrade of my Arch virtual machine.
I performed my usual system upgrade: sudo pacman -Syu
which went well. But after that my yay commands didn´t work anymore.
I got the following error message: pacman: error while loading shared libraries: libalpm.so.13: cannot open shared object file: No such file or directory.
So I looked around to see what version of libalpm was installed on my system:
ls -l /usr/lib/libalpm.so*
showed me it´s version 14: libalpm.so.14. But yay still needs version 13 of it, it seems.
So I reverted to a formerly well running state by means of a snapshot I had created formerly and saw:
arch@archlinux ~> ls -l /usr/lib/libalpm.so*
lrwxrwxrwx 1 root root 13 Feb 6 20:11 /usr/lib/libalpm.so -> libalpm.so.13*
lrwxrwxrwx 1 root root 17 Feb 6 20:11 /usr/lib/libalpm.so.13 -> libalpm.so.13.0.2*
-rwxr-xr-x 1 root root 247712 Feb 6 20:11 /usr/lib/libalpm.so.13.0.2*
Yes, yay is working that way. But as soon as I upgrade my system libalpm is upgraded to version 14 and yay stops working.
I also tried an upgrade with yay -Syu instead of sudo pacman -Syu but that way libalpm was upgraded as well, triggering the same problem.
Well, I´ve run out of ideas. Does anyone have a clue what to do to remedy the situation
I have to do a system upgrade sooner or later.
The package system has let you down… it should look after
dependencies ( including versions)
It looks like yay is hard coded to require version 13.
The only way to change that is to compile yay from source code. That may be a big task.
In apt you can stop a package from upgrading beyond a given version, but I am not sure if pacman can do that. You may have to wait.
It might be possible to have both versions 13 and 14 installed.
You would have to trick the package system by taking a copy of version 13, doing the upgrade to version 14, then putting version 13 back… and maybe fixing some symbolic link.
A real fudge.
There is not much choice. You need yay to get AUR packages.
Hi Rosika,
You need to determine which pacman package supplies
the debugedit binary. Then install it.
Guix can be installed on top of any Linux distro
I have just been reading about it myself. One can install the whole of Guix as a distro, or put its package manager (also called Guix) into any other distro.
Be careful, I am not sure it can deal wth Arch AUR.
I will try and find out
Hi @Rosika ,
I looked. It is obscure.
I think Guix uses its own repository… ie it cant use AUR
That might be interesting in itself, but it will probably not
help you with AUR.
Does anyone know?
It worked well and yay is getting along well with libalpm.so.14 now. Phew.
All yay commands work as expected again.
It took me quite a while to deal with the libalpm issue.
My internet research led me to believe that debugedit was part of the elfutils package.
Perhaps it was at some time but apparently it isn´t anymore.
I installed elfutils but libalpm was still misssing.
@nevj´s hinting to it saved the day. Thanks a lot, Neville.
OK, if I understand correctly, to upgrade yay (or install paru) you needed makpkg to work,
and that only worked after you installed debugedit. Correct?
Is this the first time you used AUR? It seems
makepkg needs to work to be able to user AUR? Is that the bottom line?
I am going to have to repeat your learning curve with Artix. Now I have a head start.
Thanks.
I think you own the solution, not me.
Regards
Neville
PS Now that you have yay working, could you do a few examples of its usage.
I tried in Artix. Your procedure worked and I got yay installed.
I tried yay -Syu and it told me not to use yay as root, and said there was nothing to do… not surprising… all my installs are from pacman not AUR.55
Things I dont understand
how do I browse AUR
why not use yay as root?
what happens if I install a package from AUR with yay… does it go into the same directories as official pacman packages?
if I have a mix of official packages and AUR packages, how do I do an update
are any packages in both the official repo and AUR
Sorry, too many questions
sorry that I couldn´t reply earlier, as I wasn´t online yesterday.
Yes, it seems that´s what it comes down to.
Yes, you do, Neville. It was your comment that led me in the right direction.
I needed to install debugedit.
I have used AUR a few times. I mainly needed it fior installing anydesk. The pacman commands wouldn´t cover it.
But it was the first time that (the new version of) yay needed the newer version libalpm.so.14.
I also use yay without sudo.
I just looked at my command history in order to verify it. Unlike pacman yay doesn´t need to be executed as root. I don´t know why that is.
I fear I don´t quite understand. What do you mean by “browsing”
Hmm, I´ve been doing it this way:
pacman -Syu for the official packages
yay for AUR packages.
Although I´m not quite sure whether the first one (pacman) is necessary at all it you use yay.
I suppose I would like to have some sense of what kinds of things are in AUR… and I suppose the answer is everything that is not in the official repo.?
Void has a website where you can search the package repo
Something like that would be what I had in mind.
Use “yay -Ss packagename” to search for packages or “yay -S packagename” to install packages. You can also use "yay -Syu to update the system. You used to be able to edit /etc/pacman.conf and add AUR to the repository list. I tried but it need not work, something about the URL, out of France, was not working.
The reason you don’t need to use sudo with yay to install packages is because yay itself handles the necessary permissions internally.
When you run yay, it automatically detects whether administrative privileges are required for the operation you’re performing. If administrative privileges are necessary (for example, when installing or removing packages), yay will prompt you for your password and then execute the operation with elevated privileges.
This behavior is similar to how sudo works, but it’s handled transparently by yay, so you don’t need to manually prepend commands with sudo. yay takes care of requesting the necessary permissions when needed, simplifying the package management process.
However, it’s important to note that yay still performs administrative tasks, and it’s essential to trust the packages you’re installing from the AUR. Always review package details, comments, and user feedback before installing packages to ensure they’re safe and appropriate for your system.
P.S.2:
Again, I contacted ChatGPT:
Yes, when you install a package from the Arch User Repository (AUR) using yay, the installed files typically go into the same system directories as packages installed from the official Arch Linux repositories using pacman.
When you install a package using yay, it retrieves the package source code from the AUR, compiles it (if necessary), and then installs the resulting package onto your system. The installation process is similar to installing packages from the official repositories.
By default, most packages installed via yay will install their files into the appropriate system directories, such as /usr/bin, /usr/lib, /etc, and so on. This ensures that the installed software integrates seamlessly with your system, just like packages installed from the official repositories.
It’s worth noting that some AUR packages may have custom installation instructions that specify different installation paths or require additional configuration steps. In such cases, yay will handle these instructions during the installation process.
Overall, yay ensures that packages from the AUR are installed properly and integrated into your system alongside packages from the official repositories.
P.S.3:
Once again ChatGPT helped with the answer:
Yes, it’s possible for packages to exist in both the official Arch Linux repositories and the Arch User Repository (AUR). This can happen for several reasons:
Community contributions:
Sometimes, packages that are available in the official repositories are also maintained by community members in the AUR. These community-maintained versions may offer additional features, customizations, or updates that aren’t present in the official package.
Variations or forks:
Occasionally, community members create variations or forks of packages available in the official repositories. These variations may include modifications, patches, or customizations that cater to specific use cases or preferences.
Testing and development:
Developers may use the AUR to distribute testing or development versions of packages before they are officially added to the Arch Linux repositories. This allows users to try out bleeding-edge features or contribute feedback before the package is considered stable enough for inclusion in the official repositories.
Package availability:
In some cases, packages may be removed from the official repositories due to policy changes, licensing issues, or other reasons. In such cases, community members may continue to maintain the package in the AUR, ensuring that it remains available to users who still want to use it.
While it’s less common for packages to exist in both the official repositories and the AUR, it’s not uncommon to find overlap between the two. When deciding which version of a package to install, it’s essential to consider factors such as package maintenance, stability, and community support.
Hi Rosika, https://aur.archlinux.org/packages
That is what I was looking for
and
Thank you for the ChatGPT explanations.
I think I understand how yay works now.
I dont feel comfortable using black boxes.
AUR packages can be source code and need compiling.
So it is a bit like Gentoo
That is true to a certain extent, yay just takes the element of having to install a package using the source-code. Take for instance the “aisleriot solitare package”!!! It does not show-up in the pacman repositories but a “yay -Ss aisleriot” shows the package within the community-driven AUR, so a “yay -S aisleriot” will indeed install the package, with all of Arch, warning otherwise.
This is why Arch does not activate AUR by default, you install at your own risk of bricking Arch!!!
It is always best to try and find packages within the pacman repositories, if one wants to keep Arch running.
There are other AUR helpers, besides yay.
Yes that is my feeling.
Especially stay away from system packages in AUR.
The odd app package could probably be safe.
If you want to risk bricking Arch, do it in VM where you can use snapshots to recover.
It seems like you guys have already managed to work this out, but just in case you don’t want to install debugedit:
What worked for me when I got that error (like 20 minutes ago) was uninstalling yay using sudo pacman -Rns yay, then re-git clone-ing and rebuilding it like I was installing it for the first time.
