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)

Reliable Updater

Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.

ie: Does it handle accurate update status on VCS packages? Does it handle accurate update status when developer fails to update .SCRINFO?

And any other unmentioned situations. Cody Learner (talk) 18:49, 22 February 2018 (UTC)

The second is an issue only pacaur has, by design to "improve metadata on the AUR". It has nothing to do with what an AUR helper should do. The first is at best a specificity, since the AUR has no perception of what a VCS package is. See FS#56602. -- Alad (talk) 20:02, 22 February 2018 (UTC)
I think the most important here to provide reliable testcase to prove the reliability of updater :-) I would suggest mb creating a repo a with some stub PKGBUILDs which could be used as testcases for criterias in the table. Actionless (talk) 20:19, 22 February 2018 (UTC)
Not sure what a testcase of such would look like, since scoring on the other criteria should guarantee reliable updates apart from some pecularities outlined above.
About the second case, it has been suggested before to create some centralized place for testing helpers instead of a few arbitrarily chosen AUR packages. However, since AUR helpers are (by definition) for the AUR, I wonder how you'd go about testing these helpers with an external repository. PKGBUILDs specifically made for testing helpers would not be accepted on AUR anyways as too specific. -- Alad (talk) 22:30, 22 February 2018 (UTC)
And what about adding packages to AUR but with some special prefix in package name (`_stub-package-test-reliable-solver`) and very explicit description ("DON'T INSTALL ME. Stub package intended for testing AUR helpers for 'reliable solver' criteria.") and so on? Actionless (talk) 23:53, 22 February 2018 (UTC)
Considering AUR helpers are something that's tolerated instead of supported, I doubt such packages explicitely targeting them with no use otherwise would have a long lifetime. -- Alad (talk) 12:00, 23 February 2018 (UTC)
See #"Reference" implementation for an alternative. -- Alad (talk) 13:29, 8 March 2018 (UTC)
I would argue this is covered by the new "Pacman wrap" column. That said there's some strange cases (e.g. rakudoAUR or nvidia-betaAUR) which some helpers can install successfully but fail to update afterward. Usually this involves version requirements (though note FS#54906). -- Alad (talk) 22:31, 18 March 2018 (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)