(optional) AUR helper in archinstall
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. With [archinstall#4447] we received yet another request with regards to this topic: The chosen approach is to add the (optional) possibility of building and installing paru and/or yay (as two of the most popular AUR helpers) using a dedicated menu entry under "archinstall" -> "Applications" -> "AUR Helpers". The menu entry is accompanied by a warning that the use of the AUR and the AUR helpers is not supported, thus potentially satisfying one of the historical concerns. In my opinion, this placement is good, as it is clearly separated from the remaining installation workflow and warns the user. However, given the previous reasoning for not including AUR helpers directly, I'd like to open up the discussion on this topic. Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers. It seems like a large portion of users install yay/paru anyway (as of writing this), and it makes sense from a repetitive-task-standpoint to allow users to choose — whether or not they want access to AUR early in the installation process, rather than us saying no and making it less accessible. Aside from apparently being a common repetitive task of setting an AUR helper up, there are also certain drivers[1] users want to pull in during installation, as well as AUR packagers would slightly benefit from this option if they want to try their packages during installation. So with this, I would like to open up the discussion — where both "yes" and "no" are welcome, but I'd appreciate some reasonings behind them as I'm most likely going to reference this mail thread if the consensus is "no". And I hope that "I don't care" people speak up too (we'll count them as leaning towards "sure, go ahead"), so I can get a reliable benchmark of what we think about it. //Torxed [archinstall#4447]: https://github.com/archlinux/archinstall/pull/4447 [1]: https://github.com/archlinux/archinstall/discussions/4075 [6338e71]: https://github.com/archlinux/archinstall/commit/6338e7116ef5405cd9b97f066e45...
On Thu, 23 Apr 2026 at 20:18, Anton Hvornum <torxed@archlinux.org> wrote:
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.
I'm firmly in that "no, because the AUR is unsupported" camp. If users can't figure out how to install an AUR helper if they think they need one, just goes to show that they /shouldn't/ be using an AUR helper in the first place.
Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers.
But AUR helpers /are/ AUR packages. Unless you're proposing adding them to the [extra] repo? Cheers, WorMzy
On 4/23/26 10:30 PM, WorMzy Tykashi wrote:
On Thu, 23 Apr 2026 at 20:18, Anton Hvornum <torxed@archlinux.org> wrote:
I'm firmly in that "no, because the AUR is unsupported" camp. If users can't figure out how to install an AUR helper if they think they need one, just goes to show that they /shouldn't/ be using an AUR helper in the first place.
I just want to put a spin on this, it's not all users that belong to this group you are describing. Some are well understood with this and simply want more convenience. I am biased obviously, but I belong to the group who know how to install them - but since `archinstall` (can) drop users to a chroot at the end, it would just be less hassle if yay/paru/whichever was there. Especially when you do installs on a weekly basis. But we agree that users not aware of the risks, should be clearly informed of the "dangers", maybe our warning was not sufficient to counter the fear. And that's okay.
Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers. But AUR helpers /are/ AUR packages. Unless you're proposing adding them to the [extra] repo?
Similar to the the commit, linked in my initial e-mail, we would add an ephemeral build users inside the target system, build the desired AUR helper, and then install it. Adding AUR helpers to [extra], would be a totally different conversation I think. Cheers for your input, it's appreciated! //Torxed
Hi, I have some questions:
With [archinstall#4447] we received yet another request with regards to this topic: The chosen approach is to add the (optional) possibility of building and installing paru and/or yay (as two of the most popular AUR helpers) using a
How do you select which AUR helpers archinstall allows to install? The wiki has an extensive page which is moderated to limit self-promotion and avoid bad/unmaintained software: https://wiki.archlinux.org/title/AUR_helpers I don't think that implementing this feature with a short allowlist will avoid similar feature requests - people will just request to add helper X instead of adding support for AUR helpers in general.
Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers.
Yet implementing the feature basically adds the ability to install an arbitrary package from AUR... Jakub
On 4/23/26 10:55 PM, Jakub Klinkovský wrote:
How do you select which AUR helpers archinstall allows to install? The wiki has an extensive page which is moderated to limit self-promotion and avoid bad/unmaintained software:
https://wiki.archlinux.org/title/AUR_helpers We would honor that list, and select a few (to begin with at least) based on their overall popularity (github stars, maintenance pace etc). I don't think that implementing this feature with a short allowlist will avoid similar feature requests - people will just request to add helper X instead of adding support for AUR helpers in general. That is something the project itself would be okay with I think, at least from my standpoint. But we'd have to start somewhere, preferably small, to see how adoption behaves. As adding more supported features in `archinstall` adds workload, it makes sense for us to start with a few. And hopefully gain more contributors willing to help adding the rest. (this is how it started and worked out with desktop profiles).
Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers. Yet implementing the feature basically adds the ability to install an arbitrary package from AUR...
Correct, `archinstall` can drop users to a chroot at the end of an installation which would allow the user to make decisions with the help of an AUR helper. But we won't be packaging AUR or dealing with conflicting packages etc in `archinstall`, but it would give the user more freedom of choice. I appreciate the questions! Thanks for takin the time! //Torxed
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
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
No. Absolutely no.
"No" (for non-technical reason): For me it looks like an encouragement or even invitation to use AUR directly, which -- in an ideal world -- should be avoided (see kpcyrd's letter above). "Yes" (for non-technical reason): Newcomers will use AUR anyway, so it's a good opportunity to educate them a bit.
users not aware of the risks, should be clearly informed of the "dangers"
For me "cleary informed" means not just using general non-informative waringns "not officially supported" and "use at your own risk", but some explanations like in the mentioned kpcyrd's letter. I.e. users should be aware of all that .so dependency business and Python troubles, and understand that they do not use Arch Linux anymore, but some kind of their own "Arch Linux downstream" distribution. Importance of paru's "localrepo" and "chroot" features (and similar features in other helpers if/when they will be added to archinstall) should be explained too. "I don't care": I customize ISO (because I need ZFS kernel modules up and running), so I already have AUR helper on it just in case:) And it is not really needed anyway, because I use local repository (at least, for packages which are important for me) to avoid troubles with dependencies. --- Andrei
participants (6)
-
Andrei Korshikov
-
Anton Hvornum
-
Brett Cornwall
-
Jakub Klinkovský
-
kpcyrd
-
WorMzy Tykashi