Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(Secure column in comparaison table)
(pikaur's interactive control flow: close, discussion reached its natural conclusion in User talk:Actionless)
 
(457 intermediate revisions by 20 users not shown)
Line 1: Line 1:
Authors of each front end should post a short (2-3 line) description of their creation, along with a homepage link and an AUR link (where applicable). A link to a screenshot page would also be nice (if applicable).
+
{{Note|'''Moderation''' — If your AUR helper does [[partial upgrade]]s ''without explicit user intervention'' (i.e, specifying {{ic|-Sy}} on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 20 September 2015 (UTC)
 +
}}
  
== Secure column in comparaison table ==
+
== Reliable Updater ==
  
Description says "tries to protect the user", I don't know what "tries" means but if we take the default behavior of aur helpers marked as secure :
+
Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.
*owl remains on cower to download deps so, it doesn't source PKGBUILD but calls makepkg without further questions, so finally, PKGBUILD is sourced.
 
*aura does the same
 
*pbfetch sources PKGBUILD (even if it removes build ())
 
*pacaur sources PKGBUILD (it can be configured to remains on cower)
 
...
 
  
As far as I know, only cower is secure (it builds/installs nothing) and spinach (and pacaur with secure on) ask before calling makepkg.
+
ie:
 +
Does it handle accurate update status on VCS packages?
 +
Does it handle accurate update status when developer fails to update .SCRINFO? https://wiki.archlinux.org/index.php/.SRCINFO
  
The only thing secure in dealing with AUR package is knowing what AUR is about.
+
And any other unmentioned situations. [[User:Cody Learner|Cody Learner]] ([[User talk:Cody Learner|talk]]) 18:49, 22 February 2018 (UTC)
  
[[User:Tuxce|Tuxce]] ([[User talk:Tuxce|talk]]) 12:50, 26 April 2013 (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 {{Bug|56602}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:02, 22 February 2018 (UTC)
: I think it only means asking the user to look and check PKGBUILD, especially for download URL. So it can be renamed to "Check PKGBUILD". -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 00:13, 27 April 2013 (UTC)
 
::My guess is that the "Secure" column is an adaptation of the "Manually Parses PKGBUILD*" column in [https://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=245047#Comparison_Table this old revision], see also the note at the bottom. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:50, 28 April 2013 (UTC)
 
:::Given that at the end, all AUR helpers (exept cower) call makepkg, PKGBUILD are sourced, so I think it should be removed. The word "secure" is just confusing.
 
:::For example, aurget can be considered more "secure" than owl or aura as it ask to review PKGBUILD before it being sourced.
 
:::[[User:Tuxce|Tuxce]] ([[User talk:Tuxce|talk]]) 20:05, 28 April 2013 (UTC)
 
::::Agreed, "Secure" without any kind of explanation doesn't mean anything. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:43, 29 April 2013 (UTC)
 
  
::::: "Secure" simply means the PKGBUILDs aren't sourced ***before*** the user has a chance to inspect the PKGBUILD himself. Makepkg does source the PKGBUILD obviously, it doesn't mean using it is insecure (but using it blindly is). For example, packer source the PKGBUILD before showing it to the user, unless the --preview option is passed. And so does pacaur (when using the bash solver), although the PKGBUILDs are scanned for potential malicious pseudo code using sudo. Spyhawk 12:07, 15 May 2013 (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. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:19, 22 February 2018 (UTC)
  
::::::So, just to include also cower in the definition, I think a more correct formulation would be: ''"Secure means that the application, by default, doesn't source the PKGBUILD at all, or, before doing it, reminds the user and offers him the opportunity to inspect it manually"''.
+
::: 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.
::::::Note though that the inspection of a PKGBUILD is always a separate human operation that the user has to do deliberately, and it's independent of the helper being used; this means that every "secure" application can be used insecurely if the user doesn't inspect the PKGBUILD, and vice versa every "insecure" application can be used securely if e.g. the user inspects the PKGBUILD through the AUR website.
+
::: 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:30, 22 February 2018 (UTC)
::::::Also, the "by default" clause is IMHO very important, in fact you could for example use packer with an alias that runs it with the --preview flag, thus making it a "secure" application, with just such a minimal change.
 
::::::By the way, I haven't used yaourt for a while, but IIRC it used to let the user review the PKGBUILD after downloading it; it's not clear why it's not considered secure.
 
::::::In the end, my opinion is that every application offers different degrees of security, and trying to sum all up in a Yes/No column is too simplistic: I would leave more verbose security considerations in the descriptions of every application above the table, or at least I would add some words in the "Specificity" column.
 
:::::: -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:41, 18 May 2013 (UTC)
 
  
::::::: I like your definition, but a shorter one would be welcome (if that is possible?). Of course the security of helper heavily depends on the user, but it is expected to take his full responsibility and check the PKGBUILDs. An "insecure" helper simply has a security flaw, independently of the user.
+
:::: 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? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 23:53, 22 February 2018 (UTC)
::::::: Yaourt does scan dependencies before letting the user having a look at the PKGBUILDs, so that is similar to what packer does by default. However, yaourt seems to do some other step in between but I haven't been able to understand why and for which purpose (yaourt's code is a bit cryptic to me, Tuxce might better explain what this is fully about here).
 
::::::: I do agree that it is hard to summarize the security aspect with a "Yes/No" box only, and so is the accuracy of the dependencies solver. Security is always done at the expense of the efficiency of the helper, and actually the "fully secure" helper are also the worst in solving dependencies. On the other hand, bash solvers are fully accurate, but are the less secure. Hopefully, this issue will be solved soon and the JSON rpc interface will become much more reliable, so helper could entirely rely on it instead of looking at the downloaded PKGBUILDs.
 
::::::: [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 12:18, 19 May 2013 (UTC)
 
  
::::::::yaourt doesn't parse PKGBUILD before user can read them (and never did).
+
::::: 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 23 February 2018 (UTC)
::::::::[[User:Tuxce|Tuxce]] ([[User talk:Tuxce|talk]]) 13:28, 25 June 2013 (UTC)
 
  
::::::::The definition I've proposed is just my attempt to interpret, in a more coherent way, the idea of "secure" you're using in the table: I don't think it can be made shorter than that, also because IMHO it's too biased as it analyzes only a little part of the problem, thus oversimplifying it.
+
:::::: See [[#"Reference" implementation]] for an alternative. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:29, 8 March 2018 (UTC)
::::::::I still don't get what you exactly mean with ''An "insecure" helper simply has a security flaw, independently of the user'': what is this user-independent ''security flaw''? If it's just the fact that the application doesn't remind the user to check the PKGBUILD manually, personally I wouldn't consider it a security flaw, in fact I think the real security flaw, which is intrinsic to the AUR, is in the fact that the user, even before launching the helper, 1) must be aware that the helper is going to source some third-party code on his machine, and 2) must be able to understand that code in order to decide if it's safe or not; now, every user should be aware of this when installing AUR packages, and the fact that the helper reminds the user or not does really make a minimal difference in terms of security.
 
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 20 May 2013 (UTC)
 
  
::::::::: I'm not referring to any situation where the user does not check the PKGBUILDs (or check but still continues despite the PKGBUILD being malicious). As previously written above, I'm referring to security flaw that sources the PKGBUILDs ***before*** the user is asked to view the PKGBUILDs himself. So a malicious code would be executed even before the user has a look at the PKGBUILD. Packer (without --preview) is the most stunning example here.
+
::::::: I would argue this is covered by the new "Pacman wrap" column. That said there's some strange cases (e.g. {{AUR|rakudo}} or {{AUR|nvidia-beta}}) which some helpers can install successfully but fail to update afterward. Usually this involves version requirements (though note {{Bug|54906}}). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:31, 18 March 2018 (UTC)
::::::::: [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 18:28, 20 May 2013 (UTC)
 
  
::::::::::Well, it seems we've fallen into a loop we can't really break: each of us has exposed enough arguments, let's leave this discussion open for a while and see if somebody else supports one or the other side.
+
== "Reference" implementation ==
::::::::::Meanwhile I've reworded the note, I think it's clearer now.
 
::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:14, 22 May 2013 (UTC)
 
::::::::::: Does the secure definition agreed among the developer and user base? Base on the discussion, the answer is no.
 
::::::::::: I myself do not think the time of sourcing PKGBUILD can be the seperate line between secure and no secure. If source PKGBUILD is danger, then source the PKGBUILD before user checking is 100% danger and after is 95% danger. Most people do not check the PKGBUILD, they just install blindly. Even if they do, few of the could find the danger hiden there.
 
::::::::::: So my suggestion is remove secure column until the definition is well understood between developer and user community.
 
::::::::::: -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 23:09, 30 May 2013 (UTC)
 
  
:::::::::::: The fact that some people don't check the PKGBUILD is irrelevant, since an Arch user is given complete responsibility over its system. In contrast, some helpers have clearly a dangerous security flaw.
+
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.
:::::::::::: [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 21:51, 1 June 2013 (UTC)
+
 
 +
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 {{ic|makepkg --pkg}} was removed with pacman 5.
 +
* Minimal language constructs in e.g. a scripting language like {{Pkg|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 {{ic|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? -- [[User:Alad|Alad]] ([[User talk: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. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 15:26, 8 March 2018 (UTC)
 +
 
 +
::Apart from {{Bug|56602}}, I can't think of a case where upstream ''opposed'' removing limitations, even if helpers directly benefited. cf. the regex support discussed in [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004036.html] 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: [https://github.com/AladW/aurutils-test/blob/master/package.t#L11-L31] -- [[User:Alad|Alad]] ([[User talk: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 [https://lists.archlinux.org/pipermail/aur-dev/2018-January/004421.html]). One prominent example that comes to mind is {{Bug|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 [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004044.html], 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. [[User:Spyhawk|Spyhawk]] ([[User talk: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 {{ic|pacman --ask}} or {{Pkg|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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:36, 17 May 2018 (UTC)
 +
 
 +
:Note: I'm unsure on the status of {{AUR|bauerbill}} and {{AUR|pakku}} on this regard. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:47, 17 May 2018 (UTC)
 +
 
 +
::Neither {{ic|--ask}} parameter nor {{ic|pacutils}} is used by pakku. It just passes {{ic|--noconflict}} to pacman, so it will fail on conflicts. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 11:22, 17 May 2018 (UTC)
 +
 
 +
:::{{ic|--noconflict}} is not a valid pacman parameter. I guess you mean {{ic|--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 {{aur|aurman}}). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:30, 17 May 2018 (UTC)
 +
 
 +
::::Yes, I meant {{ic|--noconfirm}}, just a typo. [[User:Kitsunyan|Kitsunyan]] ([[User talk: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 {{AUR|bauerbill}}). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:11, 17 May 2018 (UTC)
 +
 
 +
::::::I don't mind. Pakku provides {{ic|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 {{ic|--noconfirm}} himself. Pakku never uses {{ic|--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). [[User:Kitsunyan|Kitsunyan]] ([[User talk: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. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 17:29, 20 May 2018 (UTC)
 +
 
 +
:::::::Good point, changed with [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=522181&oldid=522150] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:48, 20 May 2018 (UTC)
 +
 
 +
== <s>Add diff column</s> ==
 +
 
 +
Alternative to [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&diff=520747&oldid=520621]. Independent of {{ic|git clone}} support (aurutils supports tar diffs and yay will probably do the same at one point).
 +
 
 +
The question is if helper with optional automatic build like {{AUR|pkgbuilder}} and {{AUR|naaman}} again don't apply and get an N/A entry. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:46, 17 May 2018 (UTC)
 +
 
 +
:Considering the significant effort it took into researching this and the build interaction column (both which I initially thought trivial), I'll merge my copy soon unless someone makes a reasonable objection. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:16, 17 May 2018 (UTC)
 +
 
 +
== <s>Extend "inactive" to include "native pacman"</s> ==
 +
 
 +
Helpers which willfully use broken behavior like {{ic|pacman -Ud}} (warranting a red entry in the "Native pacman" column) for at least 6 months should be moved to the Inactive table. In particular, {{AUR|trizen}}. Thoughts? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:57, 17 May 2018 (UTC)
 +
 
 +
:Ack from me, although I would change section name from "Inactive" to "Inactive or problematic", as criteria for belonging is getting wider. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:31, 18 May 2018 (UTC)
 +
 
 +
::You're right, "inactive" is probably misleading/too vague in this case. Thanks for the suggestion. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:11, 18 May 2018 (UTC)
 +
 
 +
== <s>Pakku now supports diff view</s> ==
 +
 
 +
Support for diff view was added in 0.12. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 17:24, 20 May 2018 (UTC)
 +
 
 +
:Thanks, added [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=522182&oldid=522181]. I hope I linked the right commit. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:48, 20 May 2018 (UTC)
 +
 
 +
::My bad, I should have linked the commit. Your link is right. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 19:17, 20 May 2018 (UTC)
 +
 
 +
== <s>pikaur's interactive control flow</s> ==
 +
 
 +
[https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=prev&oldid=522369], [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=next&oldid=522374]: Why interactive control flow is worse feature to mention than vifm or deep search? -- [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 14:16, 21 May 2018 (UTC)
 +
 
 +
:Because no idea what's that even supposed to mean or if it's more than a trivial feature. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:46, 21 May 2018 (UTC)
 +
 
 +
::but it's the same with two other examples i gave in the topic, and actually it was a link to the commit with the description [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 14:58, 21 May 2018 (UTC)
 +
 
 +
:::The first part is related to batch interaction - that you use an {{man|1|expect}} clone to achieve this is a technical detail that can already be read from the linked commit in said column. The second part about restarting operations appears trivial since most helpers have some way to continue where you've left off if something fails. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:37, 21 May 2018 (UTC)
 +
 
 +
::::But in linked column about batch interaction and pacman wrapping it's not saying the same as in a new link i was adding. the main point was the approach to resolving dependencies -- instead of computing them by my own and forcing pacman to comply i am just guessing which questions could be asked by pacman and interactively answering through expect-like mechanism, leaving user to answer to unexpected questions. That's a very big difference in compare to all other helpers. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 15:40, 21 May 2018 (UTC)
 +
 
 +
:::::I still have no idea what you mean by "forcing pacman to comply". {{ic|pacaur}} did just that, ask questions on what conflicts may occur, save the user's answer then feed it back to pacman. The only difference here is that pacaur used pacman --ask and you feed the user answer to pacman's stdin.
 +
:::::If there's some helper out there automatically overriding pacman conflicts or removing installed packages without telling the user, that's something that should be fixed on that helper's end. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:45, 21 May 2018 (UTC)
 +
 
 +
::::::The only other helper with "full" batch interaction is {{AUR|yay}}, so I guess you mean this commit: [https://github.com/Jguer/yay/commit/e88bf0f5b7f3ba3ffba01926bc3274b2f47e1efc] So does that mean it just gives you a list of conflicting packages it computed before the build begins, or "trying to be smarter than pacman" as you put it? Maybe [[User:Morganamilo]] can clarify. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:44, 21 May 2018 (UTC)
 +
 
 +
:::::: The --ask flag which have as an example actually implies --noconfirm so yes -- that's something what i consider bad behavior, because in case of some unexpected situation pacman will either do something wrong without any prompt from the user either fail [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 16:47, 21 May 2018 (UTC)
 +
 
 +
:::::::pacman isn't going to do something wrong since at least 2009 [https://git.archlinux.org/pacman.git/commit/?id=b7db46d610efd5f71d5e4e887fed7a3fd3b3dd86] when run with {{ic|--noconfirm}}. I guess what you're trying to advertise as specificity is something like "--no-confirm-but-not-really"? If so that should be explained much more precisely than two disparaging sentences in a README. Something like a wiki article on your github that would be linked from the {{ic|Batch interaction}} column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:04, 21 May 2018 (UTC)
 +
 
 +
::::::::For the last point, compare [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=522425&oldid=522397] which moves "deep search" to the {{ic|Reliable solver}} column since it's an elaborate description why and how {{AUR|aurman}} qualifies.
 +
::::::::I would argue that [[vifm]] should remain as an aurutils specificity though, since it's beyond the scope of the {{ic|Secure}} column (much like {{AUR|bauerbill}}'s trust management is) and all other helpers including pikaur have 9001 prompts before the start of any build process. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:14, 21 May 2018 (UTC)
 +
 
 +
== aurutils as pacman wrapper (external project) ==
 +
 
 +
Apparently there's this ongoing project which wraps both pacman and aurutils: [https://github.com/Cody-Learner/aurt.aurutils.based] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:39, 21 May 2018 (UTC)

Latest revision as of 17:53, 22 May 2018

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? https://wiki.archlinux.org/index.php/.SRCINFO

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)

Add diff column

Alternative to [6]. Independent of git clone support (aurutils supports tar diffs and yay will probably do the same at one point).

The question is if helper with optional automatic build like pkgbuilderAUR and naamanAUR again don't apply and get an N/A entry. -- Alad (talk) 10:46, 17 May 2018 (UTC)

Considering the significant effort it took into researching this and the build interaction column (both which I initially thought trivial), I'll merge my copy soon unless someone makes a reasonable objection. -- Alad (talk) 17:16, 17 May 2018 (UTC)

Extend "inactive" to include "native pacman"

Helpers which willfully use broken behavior like pacman -Ud (warranting a red entry in the "Native pacman" column) for at least 6 months should be moved to the Inactive table. In particular, trizenAUR. Thoughts? -- Alad (talk) 11:57, 17 May 2018 (UTC)

Ack from me, although I would change section name from "Inactive" to "Inactive or problematic", as criteria for belonging is getting wider. -- Svito (talk) 20:31, 18 May 2018 (UTC)
You're right, "inactive" is probably misleading/too vague in this case. Thanks for the suggestion. -- Alad (talk) 21:11, 18 May 2018 (UTC)

Pakku now supports diff view

Support for diff view was added in 0.12. Kitsunyan (talk) 17:24, 20 May 2018 (UTC)

Thanks, added [7]. I hope I linked the right commit. -- Alad (talk) 18:48, 20 May 2018 (UTC)
My bad, I should have linked the commit. Your link is right. Kitsunyan (talk) 19:17, 20 May 2018 (UTC)

pikaur's interactive control flow

[8], [9]: Why interactive control flow is worse feature to mention than vifm or deep search? -- Actionless (talk) 14:16, 21 May 2018 (UTC)

Because no idea what's that even supposed to mean or if it's more than a trivial feature. -- Alad (talk) 14:46, 21 May 2018 (UTC)
but it's the same with two other examples i gave in the topic, and actually it was a link to the commit with the description Actionless (talk) 14:58, 21 May 2018 (UTC)
The first part is related to batch interaction - that you use an expect(1) clone to achieve this is a technical detail that can already be read from the linked commit in said column. The second part about restarting operations appears trivial since most helpers have some way to continue where you've left off if something fails. -- Alad (talk) 15:37, 21 May 2018 (UTC)
But in linked column about batch interaction and pacman wrapping it's not saying the same as in a new link i was adding. the main point was the approach to resolving dependencies -- instead of computing them by my own and forcing pacman to comply i am just guessing which questions could be asked by pacman and interactively answering through expect-like mechanism, leaving user to answer to unexpected questions. That's a very big difference in compare to all other helpers. Actionless (talk) 15:40, 21 May 2018 (UTC)
I still have no idea what you mean by "forcing pacman to comply". pacaur did just that, ask questions on what conflicts may occur, save the user's answer then feed it back to pacman. The only difference here is that pacaur used pacman --ask and you feed the user answer to pacman's stdin.
If there's some helper out there automatically overriding pacman conflicts or removing installed packages without telling the user, that's something that should be fixed on that helper's end. -- Alad (talk) 15:45, 21 May 2018 (UTC)
The only other helper with "full" batch interaction is yayAUR, so I guess you mean this commit: [10] So does that mean it just gives you a list of conflicting packages it computed before the build begins, or "trying to be smarter than pacman" as you put it? Maybe User:Morganamilo can clarify. -- Alad (talk) 16:44, 21 May 2018 (UTC)
The --ask flag which have as an example actually implies --noconfirm so yes -- that's something what i consider bad behavior, because in case of some unexpected situation pacman will either do something wrong without any prompt from the user either fail Actionless (talk) 16:47, 21 May 2018 (UTC)
pacman isn't going to do something wrong since at least 2009 [11] when run with --noconfirm. I guess what you're trying to advertise as specificity is something like "--no-confirm-but-not-really"? If so that should be explained much more precisely than two disparaging sentences in a README. Something like a wiki article on your github that would be linked from the Batch interaction column. -- Alad (talk) 17:04, 21 May 2018 (UTC)
For the last point, compare [12] which moves "deep search" to the Reliable solver column since it's an elaborate description why and how aurmanAUR qualifies.
I would argue that vifm should remain as an aurutils specificity though, since it's beyond the scope of the Secure column (much like bauerbillAUR's trust management is) and all other helpers including pikaur have 9001 prompts before the start of any build process. -- Alad (talk) 17:14, 21 May 2018 (UTC)

aurutils as pacman wrapper (external project)

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