I am a very happy user of Manjaro on all kinds of platforms (Desktop, Laptop, Pinebook Pro, Raspberry Pi, Pinephone, …). As packaging is such a breeze in Arch/Manjaro, I set up a personal repository for my software on GitLab (which I can’t link to here unfortunately). I have now run into a very strange problem, namely pacman installing packages of an invalid architecture , but only when this package is installed as a depenency, not when trying to install it directly.
In particular, my repository contains an automatically built x86_64 version of python-thunarx from the AUR. I also have an arch-independent package dependent on that, called python-thunar-plugins-git.
Now if I add the repository on one of my Manjaro ARM machines (a Raspberry PI 4 here, but it’s the same on the Pinebook Pro), the following happens:
sudo pacman -Syu python-thunarx # refuses to install due to incompatible architecture
sudo pacman -Syu python-thunar-plugins-git # happily installs python-thunarx x86_64 as a dependency (which doesn't work obviously)
Specifying --arch "$(uname -m)" also doesn’t change anything.
This shouldn’t be, right? I mean, why would pacman install a package that is clearly built for a different architecture and is thus guaranteed to not work?
Any ideas?
Info
╰─➤ pacman --version
.--. Pacman v5.2.2 - libalpm v12.0.2
/ _.-' .-. .-. .-. Copyright (C) 2006-2020 Pacman Development Team
\ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet
'--'
Dieses Programm darf unter Bedingungen der GNU
General Public License frei weiterverbreitet werden.
Just to be clear. You have a repository, which have different folders for different architecture packages (x86_64 folder for x86_64 packages and aarch64 folder for aarch64 packages), right?
And then your pacman.conf line for your repo server should have $arch in that line, to define which architecture you are installing from.
Is python-thunarx built for aarch64 too, or only x86_64?
If it’s only built for x86_64 it will try it, if you haven’t set up the architecture stuff correctly, like mentioned earlier in this post, pacman will try installing the dependency it has access too. Which is whatever you have put in pacman.conf.
Thanks everyone for your awesome answers! I didn’t enable email notifications, thus the late answer, sorry for that.
Ah, okay. So that means even if the resulting package wouldn’t change (a Python package that just depends on an architecture-dependent other package would stay the same for example), one should still specify it as arch=(aarch64 x84_64). Maybe I misunderstood what the arch-line means. I thought it meant ”this package can only be built on these architectures” and as uncompiled Python packages can be built on any arch, I thought one just puts that into arch.
Yeah… no. That’s the problem obviously. I thought one could have one big repository containing packages of all different architectures and pacman would make sure to select the right packages. Silly me!
No, not in CI. Unfortunately, the Docker containers on GitLab are x86_64-only, so I can’t really built aarch64-packages there. Might need to use a specific runner on my Rpi4 at home for that.
Conclusion
pacman is a little blind when it comes to repositories. It assumes the repositories you give it contain packages of the right architecture and it will even happily ignore the architecture of packages in the repositories, just the name (and the version) are of interest for pacman.
, but only when this package is installed as a depenency, not when trying to install it directly.