I have been using Manjaro for 13 years & in all that time, I can say the core team are always looking to improve the user experience & don’t have a problem admitting when there is an issue. Challenges go with the territory & besides, Manjaro is built around helping a wider number of people run an Arch-based system, without needing deep tech skills. I must say, I find your comment rather strange. I have very few skills & I changed to the Testing branch no problem. When the updates land downstream, I will change back to Stable. Sometimes you need to use a fix, until a solution becomes possible. This is reality.
3 Likes
You already have the library it’s called libxml2.
The library works, the PKGBUILD just expects that version of the library to have a different name (because it was designed for Arch not Manjaro stable). That itself is a fix for software that hasn’t been updated to use the newer version yet.
It’s your decision to use AUR packages and it’s your decision to stay on stable, those choices combined have consequences and that’s what you’re experiencing now.
Whilst staying on stable isn’t usually a problem, there are times like this when things don’t line up. It’s on you to make your setup work.
Most things in the AUR are designed to work with Arch, so ideally you should be on unstable if you’re going to use anything from the AUR.
That’s exactly what you’re doing when you use the AUR.
The AUR isn’t supported by either Arch or Manjaro. It’s a collection of user created PKGBUILDs which allow you to more easily compile your own applications, it’s all on you and the maintainer to make it work.
As the link I’ve already posted twice states:
Warning: AUR packages are user-produced content. These
PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
It also means that you might have to do stuff to make them work.
libxml2 is an important package, the package managers (and presumably other packages) rely upon it. It needs to be updated properly, in line with everything else, or your system may break.
The libxml2 package is currently the same version as libxml2-legacy, thus if the latter package was pushed to stable right now you’d get errors like this:
So again you have a simple choice:
- Switch to another branch
- Edit the PKGBUILD
- Use the old PKGBUILD as @philm pointed out
- Wait
Actually there are a couple of other options:
sudo pacman -U https://mirrors.manjaro.org/repo/unstable/extra/x86_64/libxml2-legacy-2.13.8-1-x86_64.pkg.tar.zst --overwrite "/usr/lib/libxml2.so.2*"- this should be ok as the newerlibxml2doesn’t own the 2 files above and all the others are in a different directory. Run at your own risk, I haven’t tested it.- Make a dummy package
Dummy package example
It builds and doesn’t affect the update to the real package, I didn’t test with viber.
pkgname=libxml2-legacy
pkgver=2.13.8
pkgrel=0
pkgdesc="Dummy package for libxml2-legacy"
arch=('any')
license=('MIT')
package() {
echo pretending to package
}
Copy it, save it in a file somewhere, open a terminal in that directory and run this:
makepkg -i
Now you have up to 6 options and they’re all easy, pick whichever you wish.
5 Likes
@marco.righi i simply dont get it. Solutions were provided. Using an older PKGBUILD as I pointed out will simply match the state the stable branch is in. With testing or unstable branch the current AUR PKGBUILD will work.
As soon as stable branch will get updated the current PKGBUILD would also work. Anyhow you would need a rebuild.
Again, aur packages are optional and not supported.
3 Likes
Except option 4 everything needs interaction by the client. As far as i see that’s what he does not want to do.
So we need to wait on his decision. it’s his choice now, solutions were offered.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.