Talk:AUR helpers

Note: Moderation — If your AUR helper does partial upgrades without explicit user intervention (i.e, specifying -Sy on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- Alad (talk) 09:37, 20 September 2015 (UTC)

"Reference" implementation

This is an alternative to #Reliable_Updater. Instead of an arbitrary set of test packages, we could write up a "specification" on what a reliable AUR helper should do. This should also be more helpful for potential AUR helper writers who otherwise have to wade through complex, fully-featured AUR helpers.

I propose a minimal reference implementation with the following points:

• No client-side workarounds for upstream limitations. In particular, a reference implementation does not need to score full points on split packages, as makepkg --pkg was removed with pacman 5.
• Minimal language constructs in e.g. a scripting language like dash.
• Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.

My initial plan was to keep such an implementation in a man page aurhelper(7) (hosted as part of aurutils), but we can consider including on a sub-page of this article. It could be then linked from the comparison table. Thoughts? -- Alad (talk) 13:28, 8 March 2018 (UTC)

Generally agree with the idea, but I don't think there is a way around a set of PKGBUILDs that could be used to test helpers in a local AUR instance. F.e., I wouldn't define a "reliable" helper that doesn't handle split packages well. Since helpers are tolerated rather than supported, upstream limitations of the AUR might be temporary or permanent, meaning the limitation would actually be in the helper itself (f.e. like regex support). Also, I'd use pseudo code for such a reference as the actual implementation itself doesn't matter, unless you'd like to write a new minimalist helper. Spyhawk (talk) 15:26, 8 March 2018 (UTC)

Apart from FS#56602, I can't think of a case where upstream opposed removing limitations, even if helpers directly benefited. cf. the regex support discussed in [1] or the exit codes finally introduced in makepkg 5.1 which made automatic building significantly easier imo. To me it seems that the main reason we have these AUR limations is due to the minimal interest of helper writers in contributing upstream, and upstream itself having different priorities. Not sure why former is the case, the PHP codebase may play part in it - at least it does for me.

You can keep dash close enough to pseudo-code, I guess less so if you want a complete example rather than exemplary code blocks. For the PKGBUILD set, I use this: [2] -- Alad (talk) 18:34, 8 March 2018 (UTC)

My understanding is that changes that aren't invasive will be accepted upstream, but otherwise might be rejected (see [3]). One prominent example that comes to mind is FS#48796. It's not really relevant anymore since x86 has been officially dropped, but the solution would involve duplicating DB tables on the server, which isn't trivial to implement/migrate. Many of the feature requests involve non-trivial code change, which is the main reason nobody pushed patches; I dislike PHP but the language itself isn't too hard either. For regex, see the bottom of [4], which is the follow-up of your link above.

Your testsuite seems interesting (thanks for the link), but one advantage of having a fixed set of packages is that these packages might be updated and change, making these edge cases difficult to test. This happened quite a few times with my own list of test packages in the past and this was rather annoying. Spyhawk (talk) 20:20, 8 March 2018 (UTC)

Add pacui to the table?

[5] pacui^AUR is kind of an aur-helper-helper. It wraps AUR helpers to provide a nice tui and also adds some of its own features. I don't really use it my self so I can't comment on how it would fit in the table/what results it would get. Just wondering if it fits here. Morganamilo (talk) 07:27, 11 June 2018 (UTC)

Seems to be aimed at Manjaro going by the amount of partial upgrade it runs (e.g. [6]) and weird stuff like "update systemd first". Former alone makes it unsuitable for inclusion in the wiki.

There's some other of these GUIs around that might fit though, like argon^AUR. Not sure where to put them; a separate section perhaps? They don't really have unique functionality of their own besides a modified user interface. -- Alad (talk) 09:50, 11 June 2018 (UTC)

A new section like Pacman tips#Graphical front-ends could work. Probably wont be too useful if argon ends up being the only one that's suitable for inclusion. Morganamilo (talk) 12:37, 11 June 2018 (UTC)

Expand Secure criteria to include other (non-PKGBUILD) bundled files

[7], in particular [8]

The new criteria would be as follows:

• PKGBUILD, no other files -> Partial
• Other subset of files that includes the PKGBUILD -> Partial
• No PKGBUILD -> No
• All files in the git repo or tar archive -> Yes

Similar to the Diff view column. -- Alad (talk) 16:32, 4 July 2018 (UTC)

good idea, you also mentioned this for aurman a few months ago, see: https://github.com/polygamma/aurman/issues/25#issuecomment-371971155 really a good idea to implement it in a way, so that changes of all known files are being shown Polygamma (talk) 17:07, 4 July 2018 (UTC)

"All files in the git repo or tar archive -> Yes" What exactly do you mean by all files? Build files often contain non text files such as images. Git diff is smart enough to hide these but then you could consider that partial because not all files are covered.

In my opinion all a helper has to do to be secure it pause and allow the user to read the build files. The helper does not even need to offer to open them for you that's the user's responsibility. Anything more than that is nice to have but not strictly needed. Morganamilo (talk) 20:25, 4 July 2018 (UTC)

If this qualifies as "nice to have", there has to be an explicit warning that a green entry in the "Secure" column does not cover other files, files which may cause more harm than the PKGBUILD itself (such as .install files or exectuables called from the PKGBUILD). In either case it's misleading, since you either give the impression that viewing PKGBUILDs alone is sufficient (with the current criteria), or include a warning that diminguishes the value of the criteria in the first place.

Latter is similar to "Native pacman", in that you have a warning at the article top warning against any sort of pacman wrapping, and criteria in the table that ignore this warning, or even reward behavior which goes against it. -- Alad (talk) 17:07, 8 July 2018 (UTC)

That's a fair point, what about changing the name to "show files before sourcing" or something? Seems more accurate. Then it would make sense that not showing .install files to be partial. The only problem I see that it's not as hard hitting as "secure". Morganamilo (talk) 20:11, 8 July 2018 (UTC)

It cuts both ways: it's an effective deterrent against broken helpers, but it also gives the impression that using a "Secure" helper makes usage of the AUR safe, which it definitely doesn't. I'm not sure on what different name to use, though. -- Alad (talk) 17:25, 14 July 2018 (UTC)

I guess "File view" could work. -- Alad (talk) 17:44, 14 July 2018 (UTC)

Native pacman revisited

As a follow-up to #Expand_Secure_criteria_to_include_other_.28non-PKGBUILD.29_bundled_files, the way "Native pacman" is used is misleading, since it depicts wrapping pacman as a generally positive thing. This contradicts the warning bundled with the criteria, as well that using the same syntax for official and user-submitted packages blurs the lines between packages that are supported, and packages that might arbitrary broken things; latter requiring careful attention before installation.

I see some alternatives:

• Remove the column and move any entries that go against it to "problematic". The description of AUR_helpers#Discontinued_or_problematic would be adapted accordingly.
• Keep the column but remove Green/Grey colors, potentially renaming both the column and its entries.

There's benefits in both approaches but implementing the first is less effort. -- Alad (talk) 17:21, 14 July 2018 (UTC) -- Alad (talk) 17:21, 14 July 2018 (UTC)

I think the second approach is best since it offers more information/overview over the first. I propose the following changes:

• Native pacman -> Pacman wrapping (restore the original column name)
• Yes [Green] -> Literal [Grey]
• N/A [Grey] -> None [Grey]
• Partial [Yellow] -> Modified [Yellow]
• No [Red] -> Faulty [Red]

-- The color change would basically reflect the old "Syntax" column, which deliberately had no colors. See [9]. Alad (talk) 22:46, 21 July 2018 (UTC)

Works for me. I'm guessing the criteria will remain the same? Morganamilo (talk) 23:16, 21 July 2018 (UTC)

Yeah, unless someone brings new arguments to the table. I'll probably make some minor changes to fit the new wording. -- Alad (talk) 23:19, 21 July 2018 (UTC)

Actually, thinking about it how about faulty -> harmful? To me faulty kind of implies it's bugged out. While -Udd and such are usually purposely implemented. Morganamilo (talk) 23:25, 21 July 2018 (UTC)

I'm not sure, since a red entry on clean build/secure is just as harmful. I guess the latter are not done "on purpose" but due to negligence, unlike -Udd and friends as you mentioned.

Another point is whether to leave the column in place, or move it back to the end like the previous "Syntax" column. -- Alad (talk) 16:46, 23 July 2018 (UTC)

I'd argue clean build is not harmful. There is no real harm to a failed build, just inconvenience. Insecure is harmful but I believe 'insecure' reflects that.

I don't see a need to move the column as it still may contain red and yellow so it's not too out of place in between all the colored fields. Then again I have no complains against moving it either really.

Morganamilo (talk) 17:11, 23 July 2018 (UTC)

I experimented a bit with User:Svito/Deleteme, I like proposal with some changes:

• Rename criteria to Pacman wrapper - for consistency with Reliable parser and Reliable solver
• Yes - no color, table is colorful enough as it is, other columns being colorful already indicates they are different in nature so change to Literal is not requried
• N/A - no color, create Template:Dash?, use em dash to make it instantly distinguishable from Yes and other entries
• Modified - yellow
• Harmful - red, this column is otherwise colorless so having extra emphasis would not hurt, other columns have color to compliment yes/no
• move column to the left of Secure instead to preserve 3 major criteria group as well as have colorful grouping
• use Template:T? for centered entries instead of longer string

-- Svito (talk) 09:57, 24 July 2018 (UTC)

I agree with all these changes apart that I'm not sure yet on the "Harmful" wording and that the emdash is a bit too long for my taste. -- Alad (talk) 10:22, 24 July 2018 (UTC)

[10] looks like a good approach since it immediately tells what's wrong instead of throwing fancy terms around -- Alad (talk) 17:07, 24 July 2018 (UTC)

edit: I think yaourt did some more things besides splitting -Syu, like manual database manipulation (!), but I'd need to check this again -- Alad (talk) 17:08, 24 July 2018 (UTC)

Yep: [11] It writes back the local pacman db with some mangled version. If you want crazy, look no further than yaourt. -- Alad (talk) 00:29, 26 July 2018 (UTC)

Include helpers that do automatic -Sy and other bad things.

The warning at the top of the page:

Note: Moderation — If your AUR helper does partial upgrades without explicit user intervention (i.e, specifying -Sy on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- Alad (talk) 09:37, 20 September 2015 (UTC)

Is quite old and since then the table now has a "Discontinued or problematic" section. This would be a good place to include the more troublesome helpers and include a column to say exactly what is wrong with each entry. To really discourage usage maybe they could be added to their own table instead? No information on their abilities, just name and what is wrong.

Currently when a helper does something bad, there's no credible source to find that out. For example, I believe pamac refreshes the sync databases every 10 minutes, but that's just word of mouth. Reading the edit history it was 15 hours, point is this information is kind of hidden away. Morganamilo (talk) 17:02, 21 July 2018 (UTC)

I agree with this in principle. That said, I think only 2 helpers apply: octopi^AUR and pamac-aur^AUR. Both are mostly used in derivatives and other unsupported works. The real solution would be in removing these from the AUR, but ostensibly doing broken things in an unsupported user repository doesn't matter, as long as the submission guidelines are respected.

Also compare the warning in Pacman/Tips_and_tricks#Graphical_front-ends. -- Alad (talk) 22:43, 21 July 2018 (UTC)

Since those two examples are graphical helpers, perhaps we can combine this with #Add pacui to the table?. If the helper does an -Sy, we could color the Name entry red so it's immediately clear people should not use it. -- Alad (talk) 23:35, 21 July 2018 (UTC)

Yeah this is kind of a continuation of that topic. If you wanna close that in favour of this I'm all for it. Morganamilo (talk) 12:00, 24 July 2018 (UTC)