Add AUR helper option in Applications menu

[unkver]

I've been using this tool starting from 2023, and I saw myself constantly doing the same thing that takes my time - installing an AUR helper like yay or paru. I thought abt it and I guess a lot of people do that anyways, so here I decided to try contributing to an open source project for the first time.

PR Description:

This adds yay and paru as installable options under the Applications menu in archinstall. And yes, it seems to preview correctly too - under the main menu and under the applications menu.

The way I implemented this is kind of tricky - since makepkg can't be ran as root (and we are root during the archinstall), it makes a service that installs the helper the first time the user boots up their new Arch system, then deletes itself (the service). You can read more in the comments that I wrote.

Tests and Checks

• I have tested the code!

I've tested it a lot in a virtual machine under a lot of circumstances (user picks yay/paru, doesn't pick anything, doesn't make a user), and it works great so far!

It took me a while to understand how this tool works (I took heavy inspiration from the audio option in Applications), and I do understand that there might be a safer way to do this, but this is my attempt to learn and do something useful at the same time :-)

[Softer]

Few technical concerns:

1. Sudoers cleanup is not guaranteed. ExecStartPost runs only if ExecStart succeeds. If the build fails (no network, AUR down, makepkg error, power loss), /etc/sudoers.d/99-aur-helper-tmp stays in place and the user retains permanent NOPASSWD: /usr/bin/pacman. Consider ExecStopPost= for cleanup on any exit, or a trap inside the bash command.

2. Unescaped user.username in the unit file. The username is interpolated directly into the ExecStartPre/ExecStart lines and into the sudoers content. As far as I know archinstall does not currently validate username format in User.parse_arguments, so a malicious config.json could inject unit directives or break the sudoers file.

3. Dangling .wants/ symlink. ExecStartPost=rm -f .../aur-install-{helper}.service removes the unit file but not the enable symlink in multi-user.target.wants/, which systemd will warn about on every boot.

4. Multi-user. Only users[0] receives the helper, silently.

5. It's a dangerous util, so maybe it's better to hide it behind --advanced?

[unkver]

Got it, I guess I'm not good at writing services - will try to fix as soon as possible.
As about --advanced - I can see why, since AUR is maintained by Users, but how about just adding a description (like in the thing in archinstall where you choose if you have a removable drive or not) where it explains that it's not maintained by official Arch packaging people yada yada, and at the end "If you don't know what this means, choose No AUR helper". Because I do think that it's useful to have here as not an advanced feature. If it is - then might as well put UKI and disk encryption behind --advanced. But I just said about the complicated side of things, but if we're talking safety - it's honestly the user's fault, like, you should know what you're installing. And about infected packages - same thing happens with pacman too (xz utill). So I'm honestly up to just putting a description for newbies to explain what these are, but I might be wrong.

[svartkanin]

I would probably argue that this os not essential to get a system up and running and can be considered a post installation step altogether.

Especially as this goes very much into the user space by installing go or rust systemwide. At this point it doesn't fit the "installing a working system" but rather a "setup an installed system".

[unkver]

I mean, all stuff under Applications are "not essential to get a system up and running" such as print service Bluetooth etc. and are all made to reduce the time for the post install setup.

[svartkanin]

Yes it is a thin line that's why it is sometimes blurry to decide what would be a good system installation component versus a nice to have.

The current list contains setups for peripheral support and base services. Whereas AUR is a tool that is used by users to manage software that doesn't per se have anything to do with a system setup.

That's why is better to have an issue raised first to discuss instead of raising a PR right away

[Softer]

Yes it is a thin line that's why it is sometimes blurry to decide what would be a good system installation component versus a nice to have.

The current list contains setups for peripheral support and base services. Whereas AUR is a tool that is used by users to manage software that doesn't per se have anything to do with a system setup.

That's why is better to have an issue raised first to discuss instead of raising a PR right away

I was also thinking about creating a PR to add yay/paru to the app menu. I think this would be a great improvement, since many people install yay/paru immediately after installation. We already have a PR for this. Maybe we can discuss it here? If @Torxed doesn't mind this topic. :)

[svartkanin]

Happy to discuss it here, also this was a well formulated explanation of why AUR doesn't fit the picture, for different reasons #3043

[unkver]

Yay and paru are just tools, no different philosophically from installing a firewall or a print service, which are already in the menu. The concern about AUR security makes sense, but we're not adding AUR support - just the helper tool itself, which the user explicitly opts into.
My suggestion would be, as I said, to make a description that tells the user these are community tools and not officially supported by Arch, so archinstall isn't implicitly endorsing the AUR. The demand is clearly there for these tools to be available for installation.

As for the fix, should I wait to hear whether the feature direction is agreed upon first, or do I start regardless?

[Softer]

Re-read the wiki page on AUR helpers (https://wiki.archlinux.org/title/AUR_helpers). The very first thing on it is this:

Warning: AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.

So the wiki's stance isn't "don't mention them" - it's "here they are, here's how they work, here's why you need to be careful". archinstall can take exactly the same stance: show the option, put that warning in the preview word for word, never on by default. If the wiki can do that without officially recommending anything, so can we.

And yay is just a binary, it doesn't pull in any AUR package on its own. That's still entirely the user's call after install. git is a fair analogy - nobody blames archinstall for the repos people clone later.

One thing that changes the calculus on the technical side: there's no need to compile from source. Both yay and paru have -bin PKGBUILDs in AUR maintained by the authors themselves - they download prebuilt tarballs from the project's GitHub releases and just install -Dm755 them, no actual compilation. So archinstall can run makepkg -si yay-bin as the newly-created user inside the chroot (not on first boot) with a sudoers rule that lives and dies in the chroot session. No go/rust toolchain, no first-boot service, no persistent state on the target system. base-devel + git is the only build-time overhead. git stays as a runtime dependency of yay-bin, but base-devel can be removed automatically right after the build (skip the removal if the user explicitly added base-devel via Additional packages). pacman tracking is preserved. That removes the "installing a toolchain systemwide goes into user space" concern and also massively simplifies @unkver's current implementation.

Gating condition: the option should only be available if at least one regular (non-root) user is configured. yay/paru invoke makepkg internally for every AUR package, and makepkg refuses to run as root - without a non-root user the helper is dead weight, plus the install itself needs that user to run makepkg -si yay-bin. So no user = hide/disable the menu entry, and the validator should catch it for --silent/--config flows (same pattern as bootloader layout validation).

My take: --advanced only, preview quotes the wiki warning verbatim, default off. Anyone who opts in after reading that warning knows what they're getting.

The demand is obviously there (this PR, #3043, and from my own experience it comes up constantly). Mirroring what the wiki already does seems like the cleanest way to give people the option without making it look like archinstall officially recommends it.

[unkver]

Holy, I completely forgot that -bin variants exist! Guess should've RTFM before making this unnecessary service-making stuff... I will start trying to implement that - thx @Softer

[h8d13]

#4075 this won't be allowed and it works perfectly fine at least using modified grimaur instance (single python file)

[Softer]

Thanks @h8d13 - followed the trail to #4075 and #3043, appreciate the context.

My earlier comment on this PR laid out the concrete path (yay-bin/paru-bin PKGBUILDs - prebuilt tarballs, no Go/Rust on the target, --advanced only, default off, verbatim wiki warning in the preview, menu entry hidden unless a non-root user is configured). Won't re-argue it here.

Didn't know about grimaur before your pointer - took a look and it's a genuinely good fit here. Pure Python, available as grimaur-git, nothing to compile. Arguably the most archinstall-native of the three and a clean third menu option alongside yay-bin / paru-bin.

@Torxed - your "not sure that's changed" from #4075 leaves the door cracked. Given the concrete proposal above (and that the two historical objections - toolchain residue, ambiguous endorsement - now have direct answers), would you be open to revisiting? Happy to close this out if the answer is still no, but rather ask with the proposal on the table than leave @unkver mid-redesign uncertain.

@unkver - sensible to pause until there's a signal.

[h8d13]

My main argument was that yes a lot of hardware needs this regardless and they expect it to work post installation.
In my fork its also hidden under --advanced and gated with the same condition.

But building stuff like this is non-trivial, I had to modify grimaur source code for it to build packages at the end of install

[Torxed]

would you be open to revisiting?

I'm always open for new ideas, I've therefore sent out a mail to the dev mailing list (to reach a wider audience) asking for feedback on previous decisions regarding this topic: (optional) AUR helper in archinstall

It's been a controversial topic in the past, so buckle up, I'm not expecting this to be an easy topic to navigate ^^