Talk:AUR helpers

From ArchWiki
Jump to navigation Jump to search
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)

Move batch interaction as separate column?

This is probably a feature most users naturally expect from a program that builds and installs many packages in succession, by definition. It's also not trivial to implement (with only the undocumented pacman --ask or pacutils providing a proper solution) - see recent edits where helpers that supposedly qualified did not. Helpers that still view all PKGBUILDs ahead of time would get a "Partial" rating. -- Alad (talk) 08:36, 17 May 2018 (UTC)

Note: I'm unsure on the status of bauerbillAUR and pakkuAUR on this regard. -- Alad (talk) 10:47, 17 May 2018 (UTC)
Neither --ask parameter nor pacutils is used by pakku. It just passes --noconflict to pacman, so it will fail on conflicts. Kitsunyan (talk) 11:22, 17 May 2018 (UTC)
--noconflict is not a valid pacman parameter. I guess you mean --noconfirm. If it just fails rather than handle these conflicts beforehand it doesn't qualify as "batch interaction", where these conflicts are handled before the build starts (same for aurmanAUR). -- Alad (talk) 11:30, 17 May 2018 (UTC)
Yes, I meant --noconfirm, just a typo. Kitsunyan (talk) 11:34, 17 May 2018 (UTC)
Right, thanks for clarifying then. Draft of the new table: User:Alad/AUR_helpers#Active. Note that I put "No" for git diff in pakku's entry. I guess you could argue it could be Optional if you have some hook ability (same for bauerbillAUR). -- Alad (talk) 12:11, 17 May 2018 (UTC)
I don't mind. Pakku provides PreBuildCommand hook which allows user to insert his custom script, but that's quite complex task, and I think it'd be better if it was implemented in pakku directly, which I'm planning to do later.
Speaking about batch interaction, I think I misled you. Pakku will fail on conflicts only if user specify --noconfirm himself. Pakku never uses --noconfirm by its own. When I added "batch interaction" to table, I meant that pakku will ask to view files before build, and ask about installing only if it's necessary to install something right now (this mechanism is quite complex, further explanation would be inappropriate here). Kitsunyan (talk) 19:52, 17 May 2018 (UTC)
Speaking about the table you edited in the page. Since you've reordered the columns ("native pacman" is a 5th column now), it would be better to reorder their descriptions as well. Unrelated to the topic, but you mentioned it here. Kitsunyan (talk) 17:29, 20 May 2018 (UTC)
Good point, changed with [5] -- Alad (talk) 18:48, 20 May 2018 (UTC)

aurutils as pacman wrapper (external project)

Apparently there's this ongoing project which wraps both pacman and aurutils: [6] -- Alad (talk) 17:39, 21 May 2018 (UTC)

trizen and split packages

Trizen no longer works with split packages since pacman 5.1: [7] Give it a week or two and then give it a red entry in the table? -- Alad (talk) 11:49, 8 June 2018 (UTC)

I think granting a red label due to a bug shouldn't happen instantly since the bug can be fixed soon. Let's give it two weeks (one week is too short time). Kitsunyan (talk) 15:51, 8 June 2018 (UTC)
Who would benefit from that? This article is only and most factual source of comparison for AUR helpers. It would only be fair to trizen and other helpers if entries changed as soon as they were broken or fixed. -- Svito (talk) 12:15, 9 June 2018 (UTC)
It's to give some leeway to the authors who write these projects in their free time. -- Alad (talk) 14:45, 9 June 2018 (UTC)

pikaur claims to no longer split -Syu

[8], I however can't track this down to a specific commit and can't make much sense of the relevant code either. -- Alad (talk) 14:46, 9 June 2018 (UTC)

I believe it is wrapping the entire pacman -Syu call, pausing pacman after the refresh to do its own thing, then resuming pacman. As far as I am concerned this is still effectively spiting the refresh and upgrade. Morganamilo (talk) 21:33, 9 June 2018 (UTC)
Amazing. That sounds like an easy way to completely break your database when you "pause" at the wrong moment. -- Alad (talk) 17:50, 10 June 2018 (UTC)
see: - seems like pikaur really parses stdout of pacman to see what's going on. i do not understand his code either, so i have no idea what the consequences of failing to parse the output are, but it seems to be relevant to "wrapping" "-Syu" Polygamma (talk) 17:59, 10 June 2018 (UTC)
Maybe I should not have said paused. I believe pacman pauses itself when it asks the user if they want to continue. At which point pikaur continues on doing its own thing before hitting yet to that prompt. I've gathered this mostly from casually reading issues, you should probably ask the author for the specifics. Morganamilo (talk) 18:12, 10 June 2018 (UTC)
[9] closing -- Alad (talk) 13:26, 11 June 2018 (UTC)

Add pacui to the table?

[10] pacuiAUR 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. [11]) 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 argonAUR. 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)

Add back pikaur

I checked most of discussions ([12] and few others), relevant commit and I think while Actionless did not create discussion after making disagreeable changes in the past his edits should not be taken as an insult or attack on the article or anyone involved. He believed what he did was right, it is easy to revert, explain what he did wrong so he can improve and we can move on. As long as he does not break CoC occasional bad edits should be allowed to happen and will be gracefully reverted same day anyway.

As I remember Kynikos was in favor of BOLD principle, and even our own CoC starts with respect (it is beautifully written). And as much as we look up to Wikipedia for guidance on rules and practices there is still room for improvement, both systemic and personal in actually applying them to our interactions with people.

-- Svito (talk) 22:49, 11 June 2018 (UTC)

Re-added the entry; while there's reasonable cause to remove the author from the wiki, there arguably is not for his project. Now let's close this discussion and move on to #Native_pacman_criteria_and_IO_manipulation. -- Alad (talk) 10:55, 12 June 2018 (UTC)
@Svito every AUR helper author so far has wonderfully played by the rules, both in spirit and letter, and has made positive contributions to other AUR helpers. The pikaur author does none of that (on the contrary, see his aggressive behavior in for example [13] and [14], where he accuses others of misusing the table criteria which he now does himself) and I'm done with indulging both him and his project. -- Alad (talk) 09:06, 12 June 2018 (UTC)
I just looked at [15] to see on the author response, and as expected 1. personal attacks 2. repeating the same point over and over without listing to reasonable argument presented by others. With that mind it's already more than generous that the author is still allowed to post on this wiki. -- Alad (talk) 09:38, 12 June 2018 (UTC):
You need to point out any particular wiki rules violation or smth more than saying what your emotions are touched. Actionless (talk) 09:46, 12 June 2018 (UTC)
>You need to point out any particular wiki rules violation or smth more than saying what your emotions are touched
No problem.
Congratulations on violating so many rules at once. And with that: [16] -- Alad (talk) 09:51, 12 June 2018 (UTC)

Native pacman criteria and IO manipulation

Back to pikaur, even though 0.13 version with mentioned changes uses workaround to do actions between internal pacman operations it does not violate rule above this page to be unlisted and classifies as Partial native pacman at minimum. It actually passes as green because how Native pacman criteria is currently worded. Problem is that Actionless played by the rules and he found how to use ambiguity in Native pacman criteria. That is why in my opinion Alad completely removed the helper from the list - if you draw the line in the rules and somebody is playing on the edge of it is hard to not lose self-control. I do not think neither what Actionless or Alad did was wrong or bad per say, but I think there was miscommunication at place and nobody is to blame for that.

What I consider fair solution to both sides of the argument:

  • Add back pikaur with green native pacman entry as it passes current criteria
  • Start new talk on changing criteria to possibly not tolerate pikaur's tightly-wrapped native pacman

-- Svito (talk) 22:49, 11 June 2018 (UTC)

In my opinion the wording for the "Native pacman" column should be changed. It should be quite clear, that Actionless currently implemented a system in pikaur, which leads to the same results as splitting "-Syu" to "-Sy", ..., "-Su". I have no concrete suggestion for a better wording, but it should include the current edge case, used by pikaur to currently fulfill tge criterion for the green entry. Polygamma (talk) 23:08, 11 June 2018 (UTC)
[17] -- Alad (talk) 09:25, 12 June 2018 (UTC)
Also for the new criteria which was added ("do not influence pacman in other way") at least `--ask` flag now should't pass through that criteria (and --noconfirm flag is also highly questionable, from my opinion it's also not passing that criteria). Actionless (talk) 09:46, 12 June 2018 (UTC)
About --noconfirm; rest assured if some helper specifies --ask or --noconfirm to pacman -Syu without explicit user intervention, it does not pass the table criteria. As far as I know, none of the helpers in the table do so. -- Alad (talk) 09:54, 12 June 2018 (UTC)
I went back to the old wording until a different suggestion is made. I did change "unsupported" to "potentially harmful", see [18]. -- Alad (talk) 10:14, 12 June 2018 (UTC)
The important difference between my current solution and splitting Syu to Sy and Su is what in my case pacman DB stays locked so nothing is possible to affect its state in the middle. Actionless (talk) 00:52, 12 June 2018 (UTC)
Except when pikaur fails in the middle or makes some other mistake, as I pointed out in [19]. Missing the point once again. -- Alad (talk) 09:38, 12 June 2018 (UTC)


I suggest implementing this comment: [20], i.e.:

do not separate commands


do not separate commands or their actions

-- Alad (talk) 11:03, 12 June 2018 (UTC)

I think the user can see clearly that he modifies pacman's behavior if he modifies the package selection with pikaur. If the user doesn't modify the package selection and presses either Y or N, there is no modification of the requested pacman action. So I don't think pikaur separates pacman actions. -- SpineEyE (talk) 14:05, 12 June 2018 (UTC)
To me what's most important is that users can directly see from the table if a helper adds an additional layer over common commands. Additional layers means additional things that can go wrong (in general; leaving out some specifities like how pakku handles it for now). See for example pikaur displaying wrong update versions on it's wrapped "-Syu".
That's the logistical aspect I was trying to explain in [21]. AUR helpers being unsupported is one thing, AUR helpers modifying supported commands (pacman -Syu) in whatever way they think appropriate is another. Maybe we should reword the criteria accordingly, i.e. more in line with the warning at the top of the article. -- Alad (talk) 16:13, 12 June 2018 (UTC)

Relax batch interaction criteria

Right now the batch interaction column demands some automatic solution of conflicts through pacinstall or pacman --ask. As @polygamma pointed out, this might cause ill effects if there is some bug in the helper implementation: [22]

Therefore I propose to remove the second bullet from batch interaction and perhaps include --ask as a potentially harmful command in Native pacman. -- Alad (talk) 16:20, 12 June 2018 (UTC)

It's a trade off, I don't think you should relax the conditions. Marking ask as potentially harmful sure. This will make it so no AUR helper can get all green. This reflects the truth that no AUR helper is perfect. Morganamilo (talk) 16:25, 12 June 2018 (UTC)
I agree, that `--ask` usage must not be enabled by default to get the green entry in the "Native Pacman" column. But specifying the criteria in a way, that no AUR helper may ever get all entries green is not a good idea, in my opinion. "This reflects the truth that no AUR helper is perfect" is philosophical, the table with the different columns should be technical. Polygamma (talk) 16:27, 12 June 2018 (UTC)
My "vision" for the table is that encourages people to do less-than-harmful behavior as far as possible. Anyway we all agree that --ask should be added to native pacman criteria, that leaves on what to do with the second bullet in batch interaction. (As an aside, I'm a bit sad that pacinstall --remove would be problematic for the same reasons) -- Alad (talk) 16:31, 12 June 2018 (UTC)
Also I'm assuming assuming this will be grouped with -Rd and such and deserve a red entry? In which case I would argue pacman will still ensure dependency trees are never broken so it should only deserve a yellow. Morganamilo (talk) 16:39, 12 June 2018 (UTC)
Yeah, but if some core repo package like systemd or such is replaced unnoticed by an AUR version then it's still quite dangerous. -- Alad (talk) 16:41, 12 June 2018 (UTC)
True, would that be a real problem though? Given that you're still replying on pacman to remove stuff this will only happen with things like systemd-git which is to be expected. And users are expected to read pkgbuilds anyway so they should catch any package doing this maliciously. Morganamilo (talk) 16:49, 12 June 2018 (UTC)
Why does the "batch interaction" column even have to be changed? It says "ability to move [...]", which means, if the AUR helper offers an option to achieve that behavior, even if that violates the "Native Pacman" criteria, it is currently fulfilled. I guess it would be more fruitful to add a note, stating that it is impossible to have "Native Pacman" and "Full Batch Interaction" at the same time. Hence ALL AUR Helpers offering "Full Batch Interaction" destroy "Native Pacman" with that option. Polygamma (talk) 16:37, 12 June 2018 (UTC)
Actually if you used pacinstall, you have to explicitely define what packages you are going to remove and install, rather than only specify installation and do the removal blindly with --ask. If there's a conflict you didn't catch it would simply exit with an error. So to my understanding it would not be a harmful approach. Please correct me if I'm wrong. -- Alad (talk) 16:31, 12 June 2018 (UTC)
Could you end up removing a package that does not conflict my mistake though? That could be considered harmful. 18:42, 12 June 2018‎ Morganamilo
As long as you don't use `--cascade` or `--recursive` I don't think it would. i.e. if `foo` conflicts with `bar1` and `bar2`, `pacinstall foo --remove bar1` shouldn't remove `bar2` but rather exit with an error. This would require further testing though. -- Alad (talk) 16:46, 12 June 2018 (UTC)
You are right with that, but in my opinion the usage of `pacinstall` itself should not be allow to get the green entry in the "Native Pacman" column, since it is not native pacman. The GitHub repo of pacutils even lists: NOTE: alpm support for installation and removal in a single transaction is flaky; some options may be ignored. Polygamma (talk) 16:44, 12 June 2018 (UTC)
That's a consideration. Though since pacutils is both by a lead pacman developer and in the Arch repos I thought this was of lesser concern. Anyway besides the fragile approach of parsing stdout and I don't know of a better option. -- Alad (talk) 16:47, 12 June 2018 (UTC)