Adding a reference to why AUR is not bundled as an option in archinstall

[Torxed]

This closes:

• Add AUR helper option in Applications menu #4447 (comment)
• AUR Support #4075

We'll give it until 2026-04-26, to see if anything changes on the mailing list: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/VYOULH2GOJLFM2BXOFLWH3D754YXFPSL/

But the initial stance seems clear, so prepping this PR.

[Softer]

Thanks for seeing this through to a clear answer. Personally I find the outcome a bit unfortunate - I still think a gated opt-in behind --advanced with an explicit warning would have served users who end up installing an AUR helper manually anyway - but the consensus is the consensus. Appreciate the mailing list escalation.

[Torxed]

Pleasure is all mine tbh. I am in favor of adding it myself, but understand the reasons why not to even when it would be of personal benefit. But as you said, consensus is the consensus.. so all we can do is try :)

[h8d13]

I think this request was a bit miss-understood.

In original discussion, I never meant to add AUR helpers as an option: I meant having an AUR helper actually build packages for hardware that requires it.

The question was that a lot of people with out of tree drivers miss out on this working out of the box and have to use another device to set-up (misssing graphics, wifi, sound/bt).

This already works in my fork (using modified grimaur), during end of install, its possible to build AUR firmware packages for odd hardware.

[Torxed]

In original discussion, I never meant to add AUR helpers as an option: I meant having an AUR helper actually build packages for hardware that requires it.

That would be an even bigger topic to discuss, as it would mean more maintance on our side as well as being responsible for lifting in actual unsupported packages. Apologies if we misunderstood, but if this didn't fly — then adding in actual AUR packages will be an even bigger obstacle consensus wise.