Libxml2-legacy not available?

Hi,
The official Arch repo contains the libxml2-legacy library

https://archlinux.org/packages/?sort=&q=libxml2-legacy&maintainer=&flagged=

But the Manjaro repo does not. The library is not present in AUR. Can you please help me? Viber requires it, and I would like to avoid using Flatpak.

Thanks in advance

1 Like

@bill_t has referred here to the unstable branch and an installation hint.
otherwise you just have to wait until it comes from unstable to the other branches.

4 Likes

libxml2-legacy is currently in the Testing & Unstable repos:

mbn info libxml2-legacy -q | grep -Ev 'Name|Repository|Packager'
Branch         : archlinux
Version        : 2.13.8-1
Build Date     : Fri 02 May 2025 11:42:34 
Branch         : unstable
Version        : 2.13.8-1
Build Date     : Fri 02 May 2025 11:42:34 
Branch         : testing
Version        : 2.13.8-1
Build Date     : Fri 02 May 2025 11:42:34 

mbn can be found in the manjaro-check-repos package

If you need it urgently, it is not difficult to switch branches:

sudo pacman-mirrors --api --set-branch testing

then

sudo pacman-mirrors --continent && sudo pacman -Syu
6 Likes

Viber requires it

Google-earth-pro also. Building this package against libxml2 instead of libxml2-legacy works for me at the moment.

3 Likes

I tried to install it using the sudo pacman -U +URL command & got the following output:

error: failed to commit transaction (conflicting files)
libxml2-legacy: /usr/lib/libxml2.so.2 exists in filesystem (owned by libxml2)
libxml2-legacy: /usr/lib/libxml2.so.2.13.8 exists in filesystem (owned by libxml2)
Errors occurred, no packages were upgraded.

It seems my machine won’t accept the file. Thanks for everyone’s assistance on this one - it seems to impact multiple AUR apps.

Hi @TheInvisible - would you mind posting how you built this package against libxml2 instead of the legacy version? I see from the comments that libxml2-legacy is currently in testing & instable repos but not having it is preventing me from using Viber. Any assistance would be appreciated.

Thanks, Ruziel :wink:

@ruziel
It looks like you have not updated to libxml2 2.14.2 yet as that version is only in Unstable and Testing branches. Therefore at the moment, you do not need libxml2-legacy. When libxml2 updates in Stable to libxml2 2.14.2, you may or may not need libxml2-legacy depending on your setup.

1 Like

By way of illustration;

2 Likes

Thanks @jrichard326 - at the moment Viber won’t work on my machine without mlibxml2-legacy. Hopefully things work out one way or the other, once the updates come through to Stable. I’d rather not risk running one of the less stable branches. Much appreciated!

Same issue here, the missing library prevents me obviously from updating Google Earth.
Whenever i hit enter, the error about missing file appears and the update process stops bringing me back to the prompt:

[ ~]$ yay -Syu
:: Paketdatenbanken werden synchronisiert …
 core ist aktuell
 extra ist aktuell
 multilib ist aktuell
:: Durchsuche AUR nach Updates...
 -> Kein AUR-Paket gefunden fĂĽr libxml2-legacy
:: Durchsuche Datenbanken nach Updates...
 -> Pakete nicht im AUR: ksanecore5  libksane5
:: 1 Paket zu upgraden/installieren.
1  aur/google-earth-pro  7.3.6.10201-1 -> 7.3.6.10201-2
==> Pakete zum AusschlieĂźen: (z.B. "1 2 3", "1-3", "^4" oder Repo-Name)
 -> Das Ausschließen von Paketen kann zu teilweisen Aktualisierungen führen und Systeme beschädigen.
==> 
 -> could not find all required packages: libxml2-legacy 
[ ~]$

I also have no idea about the ksanecore5 and libksane5 package which cannot be found. I never installed it by myself and i have no idea for what it is required.

running pacman does not find any further updates.
Any thoughts or should i simply wait until it’s in stable?

EDIT: After changing the content of the build file from libxml2-legacy to libxml the build process for Google Earth went through and no further update notice appeared.

Did i already mention that i love the support forum of Manjaro? Great people here all around…

2 Likes

Some AUR helpers may allow you to modify the PKGBUILD before building.

Otherwise you download the files, edit the PKGBUILD and change libxml2-legacy to libxml2, then you run makepkg -si in the directory that contains the PKGBUILD.

https://wiki.archlinux.org/title/Arch_User_Repository

3 Likes

I was using yay and changed the Build file manually with an editor by simply removing “-legacy” from the line where it is documented.

Alternatively you can use PAMAC which comes with a built in editor. Works as well

2 Likes

Usually, the users do not touch the configuration files to avoid affecting their distribution. Sorry, these are palliatives, not solutions.

And this is Linux, not Windows

You do not need to touch files. You can also simply wait until it made it’s way to stable

2 Likes

Yeah, and therefor you can touch files. There’s no need to wait till someone else does. :wink:

1 Like

The AUR PKGBUILDs are done for Arch Linux, NOT Manjaro. Some packages are in other branches like testing or unstable. Either edit the PKGBUILDs as needed or switch branches. Simple. For viber, simple revert this change: https://aur.archlinux.org/cgit/aur.git/commit/?h=viber&id=8a9856701d4386ec1c3193d364ea962bc069f499. You can also do like this:

mkdir -p viber && cd viber
wget https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=viber&id=b175a2bd8159654ea23a17d67ad55a753b2d3b28 -O PKGBUILD
makepkg -si
3 Likes

I switched over to Testing for now & Viber is working perfectly. I plan to switch back after the next stable release. Thanks everyone for being part of this incredible community. More power to you all.

4 Likes

Sure, every user should know how this works and what differs it. As long as the app and it’s update is not mission critical, you can simply wait…

2 Likes

You now have three clearly defined solutions to your issue;

1. You can also simply wait until it made it’s way to stable
2. You can also do like this (the more manual approach).
3. I switched over to Testing for now & Viber is working perfectly.

All you need do is to choose the resolution that best suits you, and mark it as the solution to this topic.

Regards.

3 Likes

Newbies don’t change config files because they’re scared they’ll mess something up. Configuration files are there to be modified if needed, it’s how you configure things.

However it’s not a config file, it’s a (partial) script that builds a package.

It was made for Arch (as are most things in the AUR), and they have updated libxml2. Some packages haven’t been updated to use the new version yet, so they created libxml2-legacy and some AUR packages have started using it.

To use the PKGBUILD as is, you need to be on Arch, unstable or testing, as they’re the only ones that are up-to-date enough for it to work without changes. If you want to use it and stay on stable then it requires modification (or the old version of the PKGBUILD).

If you use the AUR you are expected to understand how it works and be able to do stuff like this. AUR helpers are just there to help automate the actual process of using the AUR.

This time read the link, it’s required reading for using the AUR:

https://wiki.archlinux.org/title/Arch_User_Repository

Here are the choices:

  1. Switch to another branch
  2. Edit the PKGBUILD so it works on stable, or use the old PKGBUILD
  3. Wait until stable has been updated

Choose whichever you want, it’s your computer. I’m just giving options.

2 Likes

There is a difference between free access to source code and configuration files, and chaos and disorder. It is not a problem to be a beginner or not (I am not). The lack of this library has cascading effects and wastes time. A distribution makes sense to exist if it is maintained correctly; otherwise, users could compile their own kernels and applications (investing their time). A well-made distribution does not waste time. I write this with regret, but it is in line with what was stated in previous answers. That proposal is not a solution but a palliative. I know that it takes a lot of effort to maintain a distribution, and I am sorry that there is none for a library like this. Linux is, first of all, cooperation, and when something does not work, there should be no shame in admitting it, but it should be an incentive to do better. It is not nice to see that a library does not work, and as a solution, the user is proposed to make changes, which will have to be retouched in the next update. I am sorry to have put my finger on the wound.