Talk:AUR helpers

Add table column for AUR helpers#Pacman wrappers

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 for File review

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)

Add warning about reading diffs

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)

Paru/Yay Unsafe Flags are Wrong

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)

adding cockpit-pacman to GUI tools section

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)

Add reference to Pacman/Tips and tricks#Graphical

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)

Other AUR helper

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)

Not sure what this does and what not, and it has over 1000 lines as a shell script. More complex helpers require a table entry for tested functionality in e.g. AUR_helpers#Search_and_build -- Alad (talk) 14:44, 13 July 2026 (UTC)

I see, then it's ok no further action needed. Mvtab (talk) 14:52, 13 July 2026 (UTC)

Inconsistency regarding paru and yay unsafe flags

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)

Add packaging-assistance tooling to "Other" section

I would like to propose adding an entry to AUR_helpers#Other for an LLM-based packaging-assistance tool. The "Other" section already contains non-wrapper AUR utilities (RPC libraries, vote utilities, query tools), and an instruction-driven assistant fits that category without violating the article's "helpers are pacman/AUR wrappers" definition.

Proposed text

Append to AUR_helpers#Other:

• aur-guides — OpenCode skill bundle that packages Arch packaging guidelines as instruction sets for LLM agents. Not an AUR helper: does not fetch, build, or install packages. Assists with PKGBUILD authoring, guideline auditing, AUR submission drafting, and RPC queries.

https://github.com/enihcam/aur-skills ||

Rationale

• The article explicitly defines AUR helpers as tools that interact with libalpm(3) or wrap pacman. The skill bundle does neither; it operates at the editor level, not the build/install level.
• The "Other" section is the established home for AUR-related tools that are not pacman wrappers. haskell-aur — {{{2}}}

{{{3}}} || not packaged? search in AUR, python3-aur — {{{2}}}

{{{3}}} || not packaged? search in AUR, raur — {{{2}}}

{{{3}}} || not packaged? search in AUR, and aur-talk — {{{2}}}

{{{3}}} || not packaged? search in AUR are all in this category.

• The entry is descriptive (capability + non-helper caveat), not promotional. It does not claim superiority over any existing helper.
• Following the do-not-make-complex-edits principle, I propose one entry first; further additions or a dedicated subsection can follow after consensus.

Questions for maintainers

1. Does the "Other" framing work, or should this go in AUR_helpers#See also instead?
2. Is the Template:Tl template the right format for an instruction-set entry (vs a wrapper entry)?
3. Should the entry link to the skill bundle's GitHub README directly, or to a specific sub-skill (e.g. aur-submission)?
4. Are there comparable LLM/agent packaging tools that should be added in the same change?

Related

This proposal parallels a separate proposal I have open on Talk:Creating_packages#Proposal: add Section 7.4 "AI-assisted packaging tools", which covers the same skill bundle under the packaging-creation workflow.

--Enihcam (talk) 16:38, 5 July 2026 (UTC)

We cannot endorse this proposal before Arch Linux adopts an appropriate policy for AI-assisted contributions. — Lahwaacz (talk) 10:22, 21 August 2026 (UTC)

Add haur to Pacman wrappers"haur" to wiki

I'd like to propose adding haur to the Pacman wrappers table.

haur is a relatively new AUR helper written in Tcl, with a pacman-like syntax, while allowing extra functionality through a flexible hook system that supports multiple languages.

Main features:

• Pacman-like interface (-S, -Ss, -Syu, -R, etc.)
• Reviews the PKGBUILD before building
• Diff view
• Uses git clone and .SRCINFO
• Handles split packages
• Clean chroot support
• Bash completion
• Modular hook system (its main distinctive feature)

According to the current criteria on this page, it fits best in the Pacman wrappers section.

AUR: https://aur.archlinux.org/packages/haur-git Repository: https://codeberg.org/NidoBr/haur NidoBr (talk) 19:54, 3 September 2026 (UTC)