Where were you when yay/paru was kill
I was at home trying to
yay
when:yay: error while loading shared libraries: libalpm.so.14: cannot open shared object file: No such file or directory
No
For now you can either use
paru-git
, or the already updatedyay
/yay-bin
packages. Please just don’t symlink the libraries togetherdon’t tell me what to do!
What’s one or more custom lost symlink on the system anyway.
Why not? I already did it and it works great.
Somebody who needs the dopamine of running yay -Syyyyyuuuuuuu 4 times a day wouldn’t be running broken and outdated *-bin packages but always target *-git alternatives /s
You can either patch the binary
sudo patchelf --replace-needed libalpm.so.14 libalpm.so.15 "$(which paru)"
sudo pacman -S --needed base-devel git clone https://aur.archlinux.org/paru-git.git cd paru-git makepkg -si
Or do both, patch the binary, then use it to install
paru-git
(which is what i did)Just update paru from source (exactly like the first time that you installed it)
Yeah. That’s how it was installed…
this hits sı close home from the last time I broke my system
welp, guess I’m keeping this thread open for tomorrow morning when I get to fixing this. Hopefully by then things will be more fixed upstream…
That reminds me, I gotta restart.
Weird. I was just having an issue with pamac and started using paru as a backup and paru is working fine last I checked.
Yeah I had to cargo install paru as a temp fix
Hasn’t this been an issue a few days ago? Maybe only with testing.
They ran arch, btw 🥲
sudo sed -i 's/libalpm.so.14/libalpm.so.15/g' /usr/bin/paru
I found a hack. Assuming you now have
libalpm.so.15
, just make a copy of it and rename it tolibalpm.so.14
:cp /usr/lib/libalpm.so.15 /usr/lib/libalpm.so.14
Edit: It’s not a permanent one and it works for the time being, can’t see the reason for the downvotes honestly.
Boy that’s… that’s one way to solve it I guess.
The redneck engineering equivalent in CS
It’s not a permanent one and it works for the time being, can’t see the reason for the downvotes honestly.
It’s just a bad idea in general. A better option would be to patch the binary to use 15. They both have the issue of forcing paru to work with a library it wasn’t explicitly designed for, but symlinking (or copying) 15 to 14 forces the hack to be “system wide” instead of restricted to a single binary
as well, your solution is “temporary” only if you remember to fix it, vs patching which is (by default) overwritten the next time paru is updated
it “works”, but it’s not something i’d recommend someone else do
I genuinely thought symlinking these files was standard because how many people I have seen suggesting it. I have had this issue so many times when I needed to that one program updated but there’s no newer libraries in AUR. Surprisingly, I haven’t had issues and I’ve been doing this past 5 years on my personal system. So I guess I consider compiling from source next time.