We have a note right above the table, would it not be better to create a new column for the information it contains? --Erus Iluvatar (talk) 08:26, 20 March 2022 (UTC)

The article went back and forth on this, the main issue being to define "batch operations" in the first place. This term was originally introduced by pacaur^AUR and comes down to 1. guessing which packages need to be replaced beforehand 2. using pacman --ask (undocumented feature) to invert pacman --noconfirm prompts from N to Y during the build process.

Making this a column with Yes/No implies this is a desirable feature. I argue that depending on undocumented features with a bug-prone implementation (what if the wrong package is replaced on the user's system?) can not be classified as such. Furthermore, it gives the impression this somehow leads to less interaction on the user's behalf, which is false (in fact, the vast majority of pacman wrappers play a game of whack-a-mole with y/N prompts). A Note is more neutral, and leaves out whether a feature is wanted or not in the middle.

In any case, the other columns, Shell completion excepted, are better suited as basic requirements for a reliable AUR helper. And as far as basic requirements go, they are relatively simple to implement for AUR helper authors looking at this article - unlike a "batch operation" mechanism. -- Alad (talk) 15:47, 20 March 2022 (UTC)

Thank you ! I better understand now the reason why this is not already done. --Erus Iluvatar (talk) 16:26, 20 March 2022 (UTC)

Auxiliary files in an AUR repository also lead to arbitrary code execution, namely .install files which are run by pacman as root. As such it makes sense for the file review column to include them. For a helper that only supports viewing the PKGBUILD, I suggest a Partial entry (after all, when noticing there is an .install file, the user can manually view it with some effort). -- Alad (talk) Alad (talk) 03:10, 8 October 2023 (UTC)

Sounds good to me :) Erus Iluvatar (talk) 15:37, 15 May 2024 (UTC)

In the light of the recent RAT malware found on the AUR, we may want to add a reminder in the warning up top, with either a link to or a rewording of the warning in Arch User Repository#Build the package?
-- Erus Iluvatar (talk) 09:48, 7 August 2025 (UTC)

I wanted to add this but can't right now due to the page protection. To avoid w:banner blindness (there's already two well-warranted banners topping the page), I'm thinking of inserting a "Tips and tricks" section at the top with a subsection "Inspect AUR packages and updates" that says something like

AUR packages are all submitted by other users without review. It is not uncommon to stumble across a malicious package update that has not been reported yet. To avoid infecting your system, read through the package before installing it.

Treat all .install files with extreme caution. Commands in these files are executed directly in your system. Most commands should instead be in the PKGBUILD file, which is more sandboxed.

AUR helpers that automatically build packages often have an option to show the package's definition on install and the changes to the definition on upgrade.

Aaron Liu (talk) 00:37, 14 June 2026 (UTC)

I feel like nobody reads this page anyway. IMO, Arch should just discourage AUR helpers as much as possible at this point. Maybe even by just deleting this whole article, or replacing it with a single "Don't use AUR helpers, review and build packages manually" line.

Hanabishi (talk) 06:03, 14 June 2026 (UTC)

Just because people don't educate themselves does not mean we have to give up documenting.

My main issue with a "Tips and tricks" is this page is not place to document AUR usage: the suggested section looks good to me, but it belongs in Arch User Repository somewhere instead :/

-- Erus Iluvatar (talk) 07:52, 14 June 2026 (UTC)

We have a warning at Arch User Repository#Build the package, but that's only going to be read by people who manually build, not those who automate with AUR helpers. Aaron Liu (talk) 14:07, 14 June 2026 (UTC)

Arch already heavily discourages AUR helpers. Doesn't stop most people from using it, nor do I see why doing that would stop it. Especially if nobody reads the page anyways. See also the effectiveness of abstinence education. Aaron Liu (talk) 14:05, 14 June 2026 (UTC)

Yeah, I'm just a bit upset about people making drama over nothing recently. 🙃️

Hanabishi (talk) 16:08, 14 June 2026 (UTC)

Some years back I reported an issue with an AUR helper where the PKGBUILD review was basically broken. It got fixed, but it took a while. With the plethora of helpers these things happen. I support rephrasing the top warning and have added Special:diff/879324. I've also worked on the crosslinked manual build process i section. Have a look if you want to adjust it. --Indigo (talk) 19:38, 14 June 2026 (UTC)

Yay and Paru both have the option to use --ask although it is opt in and is a flag that needs to be explicitly Passed.

Yay and Paru both have the --combinedupgrade flag (which causes a -Sy), although it's on by default in Yay and off in Paru.

I'm not sure if yellow is meant to mean the flag is optional or --ask is coloured yellow and -Sy always red. I don't seem to have the perms to edit it anyway so I'll leave the formatting to you. --Morganamilo (talk) 08:11, 7 October 2025 (UTC)

So if I get it right, yay should have a red entry for default -Sy, and paru no entry?

The only definition for yellow in the article is "optional", but since every wrapper supports -Sy as an option, that doesn't make sense for the Unsafe flags column. -- Alad (talk) 05:54, 5 January 2026 (UTC)

Time for another spring cleaning? Most of the helpers in this article haven't been updated in years:

• pbget^AUR: last update in 2021, reported to no longer work: https://aur.archlinux.org/packages/pbget
• yaah^AUR: last update in 2021
• rua^AUR: last update in 2024, multiple security issues ignored: https://github.com/vn971/rua/issues
• aurman^AUR: last update in 2023, no github activity
• pacaur^AUR: last update in 2021, no github activity

If no objections are raised within 2 weeks of this post, I will remove the entries. -- Alad (talk) 12:21, 27 March 2026 (UTC)

Make sense, go for it, Spyhawk (talk) 13:43, 6 April 2026 (UTC)

Special:Diff/872262 -- Alad (talk) 21:53, 26 April 2026 (UTC)

Tangential, but could Octopi and PkgBrowser's descriptions be updated to say Qt 6 instead of Qt 5? Aaron Liu (talk) 00:42, 14 June 2026 (UTC)

would it make sense to add cockpit-pacman [1][2] to the GUI tools section?

[1] https://gitlab.archlinux.org/pfeifferj/cockpit-pacman

[2] https://aur.archlinux.org/packages/cockpit-pacman Pfeifferj (talk) 16:13, 27 March 2026 (UTC)

Wouldn't this belong to Pacman/Tips_and_tricks#Graphical? I don't see AUR support in cockpit-pacman. -- Alad (talk) 21:56, 26 April 2026 (UTC)

Since graphical AUR and pacman helpers are intimately related, it would make sense to reference Pacman/Tips and tricks#Graphical in AUR helpers#Graphical. Conversely, Pacman/Tips and tricks already links to AUR helpers. -- Alad (talk) 22:00, 26 April 2026 (UTC)

Can someone add this line to 5. Other?*

aurx — A simple bash script for easily managing AUR installs.

https://github.com/mvtab/aurx ||

It's a lightweight helper, actually wrapper for git pacman and makepkg. Has install/build (through makepkg args)/download-only/search/suggest/describe. Mvtab (talk) 07:45, 31 May 2026 (UTC)

Currently, the table claims that paru does the unsafe flag -Sy with a link to the manpage that says it is the user's responsibility to clean up if that exit on the upgrade confirmation screen that is shown after a refresh. However, yay uses the exact same wording in its manpage and exhibits the same behavior, yet the table claims that yay doesn't do unsafe flags by default.

Personally, I think neither should count as supporting -Sy, as this is just the same behavior as exiting the upgrade confirmation screen when running pacman -Syu. Aaron Liu (talk) 00:41, 14 June 2026 (UTC)