Hey Arch Linux user!
Do you keep getting 404 errors when you try to install packages?
Did you rewrite your /etc/pacman.d/mirrorlist
file for what feels like dozens of times?
Did you edit your /etc/pacman.conf
file according to this Stack Exchange and forum post or that, hoping to get things to work?
If so, these tips just might help. That’s where I was, to the point of almost ragequitting Arch altogether, but trying these tips helped.
Update the package database
If you have your mirrorlist
file arranged so the ones geographically closer to you are on top, it may be that you need to update your database.
You might want to try updating your package database with:
$ sudo pacman -Sy
Or you could do a full system upgrade with -Syu
, your choice.
This landed me in dependency hell, though, see below, so I opted for just a database update this time around and it worked for me.
The reason 404 errors are common in Arch, according to a forum post I saw, is that old packages are deleted on the servers.
Therefore, if your package database is outdated pacman
will ask for old deleted versions of packages, resulting in 404 errors.
Live and learn, right?
The next level: Dependency hell
After updating the database Arch finally seemed ready to start installing packages again, but this time I fell into the dread… dependency hell. It consisted of messages like this:
:: poppler(21.07.0-1) 설치로 의존성 'poppler=21.06.1'(poppler-glib가 요구)가 깨집니다
Which, translated into English, means that the package I was trying to install (kdenlive) required I upgrade poppler
to version 21.07.0-1, which would break the dependency of poppler-glib
on version 21.06.1.
Evidenly this would ultimately lead to a dependency breakage of Gnu Image Manipulation Program via gegl
’s dependency on that specific version of poppler-glib
.
Running the install command with --ignore poppler
didn’t help, since pacman refused to install without the poppler upgrade.
Nor did trying to install with sudo pacman -Sdd kdenlive
help, since this resulted in kdenlive installing without any dependencies and the package simply did not work.
So what I did was upgrade the offending dependency by itself, which was feasible in my case because there was just one, specifying a -d
switch so the dependency version check was ignored:
$ sudo pacman -Sd poppler
When I tried the kdenlive installation again it worked, and luckily the Image Manipulation Program wasn’t broken by the poppler upgrade. It very well could have been, though, since upgrades to dependencies do cause breakages. That’s why dependency version checks exist in the first place.
By ignoring dependency version checks, therefore, you do assume the risk of dependency breakages causing malfunctions, which is a long-running issue in the open source world. Arch Linux, in particular, only allows one version of each package, raising the risk of dependency breakages–not a good combination with its fast-moving updates.
It should also be noted that running the kdenlive install with one -d
switch instead of two might have had a similar result as installing the dependency package with -d
, maybe in conjunction with --ignore poppler
.
According to man pacman
one -d
switch just ignores dependency version checks while repeating it twice like I did ignores all dependencies, which in this case meant the app wouldn’t work.
Keep Arching on… or not
I don’t claim these tips will solve every problem with the Arch package manager, but they could be helpful if your mirrorlist seems more or less in order yet all mirrors are failing with 404 errors. And if dependency conflicts are tying up your package installations and system updates after the 404 errors are resolved, the second part of the advice would come into play. If you don’t want the risk of broken dependencies, or if ignoring dependencies result in apps breaking, you should file a bug report with the relevant projects.
It’s also a valid choice to decide that maybe Arch Linux isn’t for you if you find these issues to be too much trouble. Arch is a purposefully fast-moving distribution and by design requires a level of expertise or at least bloody-mindedness. There are user-friendlier Arch-based distributions like Manjaro that stay a little behind the development curve and are said to be more stable as a result. The price is in staler packages than mainline Arch, but it’s my understanding packages are still newer than in something like Debian. Besides, truly cutting-edge users don’t find even Arch packages new enough and turn to the Arch User Repository for development versions or compile directly from project Git repos.
In the end you have to decide how important newer packages and upgrades are to you, and how much hassle you’re willing to put up with. If you want to keep going with Arch Linux, hopefully this post is helpful to you.