On 4/23/26 9:17 PM, Anton Hvornum wrote:
Over the years, one of the most requested features by a long shot (statistics
based on memories and conversations) for `archinstall` is having access to AUR
helpers.
So far, the answer to this has always been no "because the AUR is unsupported".
Historically, the previously existing AUR feature was removed in commit
[6338e71] as a prerequisite in order for `archinstall` to become adopted as an
official package.
If I remember correctly, the reasoning back then revolved around the support
staff being potentially unhappy/overrun by workload, and also because the "AUR
is not officially supported" argument.
From what I can tell the number 1 issue people have with "broken Arch Linux
installs" are keyring issues, followed by number 2 "AUR packages conflicting
with official packages in ways that are non-trivial to resolve".
For the official repos we have extensive tooling to rebuild packages when
needed, Debian allows you to have multiple versions of the same shared library
installed at the same time, but on Arch Linux with AUR packages, when
libfoo.so.3 updates to libfoo.so.4 it's on you to know what to do.
With .so provides= it got slightly better so pacman is going to refuse a
transaction that would leave programs in a broken state, which would otherwise
possibly rendering your computer unbootable, but you may then get stuck in a "I
can't update anymore" situation.
I'm not really up-to-date with AUR helpers, but since most are just plain
makepkg wrappers there are some situations they won't be able to solve for you:
Say you have libfoo.so.3 from the official repos, and you have both an [extra]
package and an AUR package linking against it. They both explicitly depend on
`libfoo.so=3-64` so you don't accidentally break your system. Now a new version
provides libfoo.so.4 instead, Arch Linux staff used [extra-staging] to prepare
all official packages, so you get the new library together with binaries that
are all compatible with that new library, but the pacman transaction fails to
resolve because there's no update available for your AUR package - which you
can't build because makepkg would need to have libfoo.so.4 installed first.
The best solution for this is either forcing a partial upgrade and hoping that
AUR package wasn't too important in case you unexpectedly reboot, or temporarily
uninstall the AUR package, upgrade to libfoo.so.4, build and install the AUR
package again (also hoping your computer would still boot if it unexpectedly
reboots without that software installed).
Some AUR packages avoid this by depending on 'foo' instead of the
'libfoo.so=4-64' they actually need, which means the update is going to succeed,
but the AUR binary is from then on going to crash with a dynamic linker error
until you instruct your AUR helper to rebuild and reinstall that package.
This is the notorious "error while loading shared libraries: libalpm.so.15"
As far as I know there is no AUR helper that hand-holds you through any of that,
the only one I've seen that is in a good position to deal with this would be
aurto[0]. Paru seems to have options for `LocalRepo=` and `Chroot=`, so could
manage that situation as well, but it seems you need to know about and opt-into
them (and aurto you also explicitly need to instruct to rebuild).
[0]: https://github.com/alexheretic/aurto
With python packages it's slightly worse because there's no .so-provides
equivalent, when a new python version releases you just need to know to rebuild
your AUR python packages because the .pyc files are incompatible, and you are
going to have AUR python software/libraries in a broken state until then. I've
seen people with many years of Arch experience getting tripped up by this (and I
don't blame them for that).
I'm generally slightly in favor of having AUR helpers in the [extra] repository
(if we don't move any AUR helper then archinstall itself would effectively need
to become an AUR helper), but I also think we need better helpers first. I
believe the problems I described are the main reasons how people break their
Arch Linux installs and why Arch Linux still has a reputation of being
unreliable/breaking easily - if you just stick to the official repos you are
most likely going to be fine, and this is generally what I recommend any
beginner to do.
For the reasons outlined above, and as things are right now, if you opt into the
AUR, you effectively opt into "are you ready to become an Arch Linux downstream"
and I think many people are not aware that this is what they are signing up for.
If there are in fact AUR helpers that handle all of this correctly, I would be
very happy to learn about them.
cheers,
kpcyrd
