On 4/24/26 1:14 AM, kpcyrd wrote:
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
As always, insightful and exactly what I was hoping for! Constructive
feedback and a solid foundation to base our consensus on.
I also agree with you on everything, so I don't have much to add other
than to highlight the fact — that I hope AUR helpers in the future can
become better at resolving conflicts. Perhaps even do partial upgrades
in the future with the helper of something like [ALPM].
And it would obviously greatly help `archinstall` maintenance if AUR
helpers were to be adopted into [extra]. Otherwise, as you pointed out,
`archinstall` would become a `makepkg -si` wrapper in its own right.
Again tho, I really appreciate you taking the time to outline good
reasons for a very polite "no", it helps us communicate with the users
clearly why we keep rejecting the feature.
//Torxed
[ALPM]: https://gitlab.archlinux.org/archlinux/alpm/alpm
