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?