Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(Default sorting for entries: re)
(Add back pikaur)
 
(305 intermediate revisions by 11 users not shown)
Line 2: Line 2:
 
}}
 
}}
  
== Comparison table - build directory ==
+
== pikaur ==
  
Considering /tmp is mounted as tmpfs on Arch, and the potential downsides from building in RAM (running out of space), I think a column with the default build location for various helpers would be helpful.  
+
Due to conflicting and non-resolvable opinions regarding how {{AUR|pikaur}} handles the ''Native pacman'' column (see [https://github.com/actionless/pikaur/issues/201]) as well as lacking documentation about the project in general, this helper was moved from the main [[AUR helpers]] article to its discussion page.  
  
The default values I've garnered so far, assuming TMPDIR is not set:
+
In the unlikely event that both of these issues are addressed, the entry may be moved back to the article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:09, 15 June 2018 (UTC)
  
* aurutils: $XDG_CACHE_HOME
+
{| class="wikitable sortable" width="100%"
* pacaur: $XDG_CACHE_HOME (changed from /tmp, see [https://github.com/rmarquis/pacaur/commit/c5d750f75f040b21249fff100a2c8875348d03d1])
+
! Name !! Written In !! Secure !! Clean build !! Native pacman !! Reliable parser !! Reliable solver !! Split packages !! Git clone !! Diff view !! Batch interaction || Shell completion !! Specificity
* bauerbill: $PWD/build
+
|-
* pkgbuilder: $PWD, /tmp when specified with -S
+
! {{AUR|pikaur}}
* packer: /tmp (TMPDIR)
+
| Python || {{Yes}} || {{Yes}} || {{Y|[https://github.com/actionless/pikaur/issues/201 Partial]}} || {{Yes}} || {{Yes}} || {{G|[https://github.com/actionless/pikaur/commit/d409b958b4ff403d4fda06681231061854d32b3c Yes]}} || {{Yes}} || {{Yes}} || style="text-align:center;" | 1, 2, 3 || style="text-align:center;" | bash, fish, zsh || [http://0pointer.net/blog/dynamic-users-with-systemd.html dynamic users], [https://github.com/actionless/pikaur/tree/master/locale multilingual], sort by votes/popularity, [https://github.com/actionless/pikaur/pull/191 print news]
* yaourt: /tmp (yaourtrc)
+
|-
 +
|}
  
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:16, 1 April 2016 (UTC)
+
== "Reference" implementation ==
  
: Yes, this could be useful. Although you'd want not to use color here, since users that know what they're doing would prefer to use /tmp (or setting up BUILDDIR to /tmp). --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 11:15, 3 April 2016 (UTC)
+
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.
  
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
+
I propose a minimal reference implementation with the following points:
::: Well, while it does have benefits for some users, it's still a bad default. As you say though, this is easy enough to change either way, unlike any of the behaviour described in the other columns.
 
::: We could leave out the colors, but mention the drawbacks/benefits in the "meanings" paragraph. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:35, 4 April 2016 (UTC)
 
  
:::: It is bad default because some users have no idea about what they are doing, but this is strictly related to user preferences. Adding the meaning instead of colors sounds like the perfect solution to me. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:35, 4 April 2016 (UTC).
+
* 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.
  
== Multi-thread support ==
+
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)
  
This also made me wonder if tools differentiate regarding multi-thread support (seems related, e.g. cower has a defaulted option for it). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (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)
  
: AFAIK, besides cower, packer [http://kmkeen.com/multithreaded-bash/] and bauerbill ({{ic|download.sh}} amongst others) have multiple threads. aurutils also uses aria2c for downloads, if that counts.
+
::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.
: The benefits of multiple threads are however not always clear:  
+
::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)
:: * by my understanding, cower uses multiple threads, but with one query per package [https://github.com/falconindy/cower/blob/master/cower.c#L667] (compare against multiinfo).
 
:: * More generally, tasks (like dependency solving) can be sped up by using different methods which need to be called less often
 
:: * Building packages would almost always be done sequentially: dependencies have to be installed (resulting in pacman locks), and there's {{ic|-j}} in {{ic|makepkg.conf}} anyway.
 
: Regardless, there are some large differences in AUR helper speed (with bauerbill being ahead of the rest). But I'm not sure how to quantify this in the table ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:31, 3 April 2016 (UTC)
 
  
:: Multi-thread support doesn't necessarily mean the helper is better. In cower case, multi-thread support was implemented before multiinfo was available in the RPC interface, and as of today using multiinfo is less complex and faster than using multiple info threads. Since it is difficult to implement multiinfo support without an important rewrite, cower multithreading is more a drawback than an advantage.
+
::: 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.
:: As for speed, it's indeed very hard to quantify in a meaningful manner. For example, pacaur dependency solver is slower than bauerbill's solver, but on the other hand it is designed to compute more stuff than other helpers up front in order to avoid bothering the user once the install process is started. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 13:42, 3 April 2016 (UTC)
+
::: 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)
  
::: Interesting. Actually, I did not want to induce a "speed" column, rather the opposite. As you both say, always very difficult to choose a fairly universal/comparable benchmark, so "speed" as such is better be left out of comparison (as a column). If one wants to mention it, it might be useful to have a general remark at the top of the table, or somewhere else in the article, quoting some of the influencing factors you name; perhaps linking to (re -j) [[Makepkg#MAKEFLAGS]] and (re Skyhawk's remark above) [[Makepkg#Improving compile times]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:01, 3 April 2016 (UTC)
+
== <s>trizen and split packages</s> ==
  
:::: In hindsight, the only thing of relevance here is the use of the old {{ic|info}} interface over {{ic|multiinfo}} (with newer versions of the RPC, both are identical). For example, cower puts a drastic load on the AUR due to its use of one request per single package. I think the most effective way here is to migrate to helpers that implement the new interface and leave those that don't in the past. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:14, 22 February 2018 (UTC)
+
Trizen no longer works with split packages since pacman 5.1: [https://github.com/trizen/trizen/issues/171] Give it a week or two and then give it a red entry in the table? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:49, 8 June 2018 (UTC)
  
: may be one could come up with sort of "benchmark" (list of different commands related to querying or installing packages) and run them with different AUR helpers on one machine? that would be useful for both users (to see which one is faster now) and for developers (to improve the weak points of their apps). btw pikaur is using "Double Team" technique -- it's splitting itself into multiple threads to raise its evasiveness in face of big performance threat. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:26, 8 March 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). [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 15:51, 8 June 2018 (UTC)
  
:: Well, as pointed out above, speed isn't everything. e.g. aurutils has one of the fastest dependency solvers, but it throws away information like versioned deps or {{ic|provides}} in the process. Maybe this is of relevance: [https://github.com/polygamma/aurman/wiki/Description-of-the-aurman-dependency-solving#benchmarks---these-results-are-on-my-machine-your-mileage-may-vary]
+
::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. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 12:15, 9 June 2018 (UTC)
:: I'm also not sure how far we should advocate threads, since the need for them partially arises from upstream limitations: {{Bug|49089}}, [https://lists.archlinux.org/pipermail/aur-dev/2016-April/004027.html] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:14, 8 March 2018 (UTC)
 
  
== Reliable Updater ==
+
:::It's to give some leeway to the authors who write these projects in their free time. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:45, 9 June 2018 (UTC)
  
Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.
+
:::: [https://github.com/trizen/trizen/commit/f0a9dfe408d41117c11c364ed98796eeca9b35c2] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:01, 15 June 2018 (UTC)
  
ie:
+
== <s>pikaur claims to no longer split -Syu</s> ==
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. [[User:Cody Learner|Cody Learner]] ([[User talk:Cody Learner|talk]]) 18:49, 22 February 2018 (UTC)
+
[https://github.com/actionless/pikaur/commit/8149c594eae8b8aa3f91b9ffbe1341d95a216374], I however can't track this down to a specific commit and can't make much sense of the relevant code either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:46, 9 June 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 {{Bug|56602}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:02, 22 February 2018 (UTC)
+
:I believe it is wrapping the entire {{ic|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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 21:33, 9 June 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.  [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:19, 22 February 2018 (UTC)
+
::Amazing. That sounds like an easy way to completely break your database when you "pause" at the wrong moment. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:50, 10 June 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.
+
::: see: https://github.com/actionless/pikaur/issues/201#issuecomment-395962657 - 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" [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:59, 10 June 2018 (UTC)
::: 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)
 
  
:::: 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)
+
::::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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 18:12, 10 June 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 23 February 2018 (UTC)
+
:::::[https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=525604&oldid=525603] closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:26, 11 June 2018 (UTC)
  
== <s>"minimizes user interaction" is a misnomer</s> ==
+
== Add pacui to the table? ==
  
After that 'criteria' was removed it's leaving some gap in comparison.
+
[https://github.com/excalibur1234/pacui] {{AUR|pacui}} 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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 07:27, 11 June 2018 (UTC)
I think we ned to come up with some better wording to describe those AUR helpers which allowing to review all the packages at once and next it's just building them without interrupting and asking more questions from user for each package.
 
I think it's quite crucial quality for application of such kind and for user it could be quite annoying installing each AUR helper and just trying to install two packages to see if it will ask all the questions right at once or before each package build. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:28, 22 February 2018 (UTC)
 
  
: Sorry, i've just noticed what you also added asterisk to Secure field to address that problem. But what do you think about moving it into separate column? Because i don't think it's so much about reviewing PKGBUILDs but also about other kinds of questions, like installing dependencies or package conflicts. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:32, 22 February 2018 (UTC)
+
:Seems to be aimed at Manjaro going by the amount of partial upgrade it runs (e.g. [https://github.com/excalibur1234/pacui/blob/master/pacui#L1251]) 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 {{AUR|argon}}. 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:50, 11 June 2018 (UTC)
  
:: About the other kind, any helper that supports makepkg's --noconfirm can install dependencies without query. I find it questionable to make "predicting conflicts for currently installed packages" or somesuch a core feature (which a separate column implies), since the issue might not present itself in the first place e.g. through a local repo or containers. Not to mention the original point, that you can still get up to 200+ prompts with helpers implementing this feature.
+
::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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 12:37, 11 June 2018 (UTC)
:: That said, the asterisk was just something I've added quickly. A compromise may be a sensibly named column that isn't colored, akin to the shell completion column. ("linear", "batch" perhaps, compare "linear vs tsort" in [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&oldid=474640]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:23, 22 February 2018 (UTC)
 
  
::: I suggest to simply use "batch inspection" in the specificity column instead of creating a new column. The main purpose of table imho is to be a quick reference of the status of the main steps of the process, rather than being an extensive description of each specific features. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 16:37, 23 February 2018 (UTC)
+
== <s>Add back pikaur</s> ==
  
:::: Sounds good to me. I'll edit it accordingly unless there's more feedback to offer. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:15, 23 February 2018 (UTC)
+
I checked most of discussions ([https://github.com/actionless/pikaur/issues/201] and few others), [https://github.com/actionless/pikaur/commit/de9824fd7cd95530a648c691f4d784bc4d10ebfb relevant commit] and I think while [[User:Actionless|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.
  
::::: Done: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=511910&oldid=511814]. Suggestions on a precise name for aurman/pacaur's "deep search" feature for the specifity column? (e.g. pkgbuilder, trizen, aurutils have none of that) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 24 February 2018 (UTC)
+
As I remember [[User:Kynikos|Kynikos]] was in favor of [[Wikipedia:Wikipedia:Be bold|BOLD]] principle, and even our own CoC starts with [[Code of conduct#Respect|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.
  
:::::: I am not good at coming up with precise names, but let me explain the intention behind the feature. Maybe that will help one of you coming up with a precise name. Most dep solving algorithms look at the unfulfilled dependencies only, but that can lead to not finding a valid solution on rare occasions. Example: You have package A installed on your system and A needs "B". "B" is being provided by a package called B directly, but you fulfilled that dep with another package called B_1. Now you want to update package A to a newer version and also install package C. C conflicts with B_1, and B_1 only. If the dep solving algo just looks at unfulfilled deps, it will ignore B, because B_1 is installed. But that conflicts with C, so no solution is being found. "Deep search" of aurman ignores everything installed and is thus able to find the solution of removing B_1, installing B and C and upgrading A [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 16:00, 24 February 2018 (UTC)
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:49, 11 June 2018 (UTC)
  
::::::: I had written "dependency solving independent from the installed packages (optional)" for the "deep_search" feature in the specificity column of aurman, but that has been [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=next&oldid=512105 deleted]. Tbh I cannot really follow the argumentation behind the removal. Why should the circumstance that it is almost never needed be a criterium to not put it in that column? It's nevertheless a feature which is unique by that helper, which makes it a specificity. Besides that: If one wants to install some package with another AUR helper and finding a solution fails, that "deep_search" feature could exactly be what he needs. And stating that the column is not a full features list, how does that matter for the removal of the entry? It is just one of many features... If this is the wrong place for a discussion about that removal - sorry, where do I have to put it? [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 07:46, 27 February 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]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:55, 12 June 2018 (UTC)
  
:::::::: This is the correct place. I think the main objection is that it's a rather long description of a single feature - as you may notice in the column, specifities are usually not longer than a few words. I've went with Spyhawk's proposal for now to use "batched interaction", [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512180&oldid=512148] but we can leave this discussion open for further proposals. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:09, 27 February 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 [https://github.com/polygamma/aurman/issues/91] and [https://wiki.archlinux.org/index.php/User_talk:Actionless], 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:06, 12 June 2018 (UTC)
 +
:: I just looked at [https://github.com/actionless/pikaur/issues/201] 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:38, 12 June 2018 (UTC):
  
:::::::: What does "bootstrapping packages" mean? [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512764&oldid=512724] Also what helpers do support versioned dependencies, and is it really worth including as a specifity due to the rarity of their occurence? Compare to the note on architecture specific fields which could extend instead, adding {{Bug|54906}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:08, 5 March 2018 (UTC)
+
: You need to point out any particular wiki rules violation or smth more than saying what your emotions are touched. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 09:46, 12 June 2018 (UTC)
  
::::::::: Well, I googled quite a bit do come up with a term that describes what I mean, maybe the name isn't good. Example is the mingw-w64-gcc package - installing packages for building and then removing them again is meant. Regarding the versioned deps: Two examples I know for sure: trizen and pikaur. Wanting to install "aurman-git>1.0" yields in both cases: Not found. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 15:20, 5 March 2018 (UTC)
+
::>You need to point out any particular wiki rules violation or smth more than saying what your emotions are touched
 +
::No problem.
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#Respect_other_users
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#Respect_the_staff
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#No_trolling
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#Do_not_flame
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#Be_responsible
 +
::* https://wiki.archlinux.org/index.php/Code_of_conduct#Ineffective_discussion_.28.22bikeshed.22.29
 +
::Congratulations on violating so many rules at once. And with that: [https://wiki.archlinux.org/index.php/Special:BlockList] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:51, 12 June 2018 (UTC)
  
:::::::::: Well anything supporting {{ic|makepkg --rmdeps}} can install packages and remove them again. E.g. aurutils can do that to a further extent since it uses a local repo, but it can't build mingw-w64-gcc as it has a too rudimentary dependency solving algorithm.
+
::: I'd like to reopen this discussion, and point out all the answers found here: https://github.com/actionless/pikaur/issues/201 One really has to discuss, what to do with pikaur from now on, regarding the table in the wiki. I surely can only speak for myself, but I am not interested in validating the technical claims made by Actionless regarding pikaur, to ensure, that it is really doing what he claims it to be doing. Since the table should give a technical overview, that has to be done, and I am not sure, if anyone else is willing to do this, after this discussion. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 20:15, 14 June 2018 (UTC)
:::::::::: I'll add a note then with the above bug report and {{ic|aurman}}, {{ic|pacaur}}. I'll leave it to the authors of other helpers to add to the note if their helper supports versioned dependencies. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:38, 5 March 2018 (UTC)
 
  
::::::::::: I've just used "deep search" and added a link to your awesome post on the aurman dependency algorithm. [https://wiki.archlinux.org/index.php?title=AUR_helpers&type=revision&diff=512786&oldid=512784] Is this agreeable enough to close this discussion? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 5 March 2018 (UTC)
+
:::: As I pointed out in [[#Proposal]] I'm definitely done with investing any more time in this. After 200 comments on github I thought to have found a satisfactory solution, then out of the blue the pikaur author started making preposterous remarks on other helper ''authors'' with no technical value or relevance whatsoever. Since furthermore the project is in constant shift and no real documentation is given, expecting to keep such entry updated is beyond reasonable. Unless there's volounteers I suggest to remove the entry again and leave some notice similar to what's done in [[Bitcoin#Bitcoin software]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:46, 14 June 2018 (UTC)
  
:::::::::::: Seems fine to me :) [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 20:56, 5 March 2018 (UTC)
+
::::: I have a better idea: move the pikaur entry to the discussion with an appropriate note. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:57, 15 June 2018 (UTC)
  
:::::: What about "batched interaction"? [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 17:18, 24 February 2018 (UTC)
+
:::::: Done, closing. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:10, 15 June 2018 (UTC)
  
== <s>Separate table for unmaintained/old helpers</s> ==
+
::::::: You might go even further and more to the point. Consider changing the note in [[AUR helpers#Build and search]] to something like this: {{Note|The content of this section is peer-reviewed and modifications require a discussion in [[Talk:AUR helpers]]. Furthermore, to avoid unreasonable competition and abuse of the specified criteria to get "greener" results, only projects whose development is driven by purely technical arguments can be listed in the tables.}} I'm not sure if the motivation is understandable by just reading the note, maybe you can come up with something better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:50, 15 June 2018 (UTC)
  
Right now the table is filled with entries that are no longer relevant apart for historical reasons (pacaur is one example that reached prominence, but there are many others like packer, aurget, burgaur, etc.). Since they technically still "work", I wouldn't remove them from this article, but either:
+
::::::::This is a bit over the top. New wording would imply that something bad like this already happened and to be expected to happen again in the future. Worst case scenario of resolving original topic that I opened already happened and I regret taking any part in it. There is no reason to push narratives even further. I want this misunderstanding to end and be forgotten not engraved into Draconian laws. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:26, 15 June 2018 (UTC)
  
* keep them in the same table with grey-colored columns (compare [[de:AUR Hilfsprogramme]])
+
:::::::::I agree that this is an exceptional case only so I don't think stricter notes/wordings are necessary. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:16, 16 June 2018 (UTC)
* put them in a separate table
 
* put them in a separate table with grey-colored columns
 
* put them in a list, bulleted or using [[Template:App]] (compare [[Arch-based_distributions#Inactive]])
 
  
Thoughts? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:00, 25 February 2018 (UTC)
+
::::::::: I agree, that going further would be too much. But I've got one question to @Svito - Why do you think, that this is only a "misunderstanding"? And at which point? [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:01, 16 June 2018 (UTC)
  
:I think any of those options are good (along with a warning or note). Are any of the older packages simply "feature complete" (no updates since the author considers the program done)?
+
== Native pacman criteria and IO manipulation ==
:{{Unsigned|01:22, 26 February 2018‎ |Rdeckard}}
 
  
: I like the solution with the grey-colored columns in the same table the most. Everything stays in place, but it's visually easy to see which projects are still "relevant" [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 09:12, 26 February 2018 (UTC)
+
=== <s>pikaur</s> ===
 +
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 [[User:Actionless|Actionless]] played by the rules and he found how to use ambiguity in Native pacman criteria. That is why in my opinion [[User:Alad|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 [[User:Actionless|Actionless]] or [[User:Alad|Alad]] did was wrong or bad per say, but I think there was miscommunication at place and nobody is to blame for that.
  
:Dealing with the table alone doesn't make much sense, what about the lists above it? Would they be split or greyed out as well? How would you call the split sections - "unmaintained" vs "supported" or something like that? I know that you won't like the sound of "supported" here, but I can't think of a better alternative right now. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:57, 26 February 2018 (UTC)
+
What I consider fair solution to both sides of the argument:
:: Would a column with the last update date or last release date give an idea whether the helper is actively maintained or not? -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 22:41, 1 March 2018 (UTC)
 
  
:::A problem with that is that it would get frequently outdated for the active projects. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:52, 2 March 2018 (UTC)
+
* Add back pikaur with green native pacman entry as it passes current criteria
::::True and you think showing only the year of the last release date would not be precise enough? -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 08:04, 2 March 2018 (UTC)
+
* Start new talk on changing criteria to possibly not tolerate pikaur's tightly-wrapped native pacman
  
:::::In my case, aurutils is unlikely to get another release until 2019-2020 so it would appear quite inactive even though it is anything but... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:50, 2 March 2018 (UTC)
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:49, 11 June 2018 (UTC)
  
::::: You'd need more than a date to decide if a project is actively maintained anyway. Some project are well established with very few bugs, while other got only some recent but very minor code update while still ignoring the most blatant issues for many years. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:25, 2 March 2018 (UTC)
+
: In my opinion the wording for the "Native pacman" column should be changed. It should be quite clear, that [[User:Actionless|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. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 23:08, 11 June 2018 (UTC)
  
::::: Then in my opinion splitting the table in 2 sections, maintained/inactive based on your expert judgement of the helpers (a mix of last release date and future expected dev) would be good. Keeping, for the moment at least, the same format eases comparison between current and legacy helpers. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 16:23, 2 March 2018 (UTC)
+
:: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=525688&oldid=525636] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:25, 12 June 2018 (UTC)
  
::::: See [[Synchronization_and_backup_programs]], why not using a maintained column like there. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 17:08, 4 March 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). [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 09:46, 12 June 2018 (UTC)
  
:::::: So I guess [[Template:Yes]] for active development, [[Template:Y]] for inactive but with an "available" maintainer, and [[Template:No]] for unmaintained? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:22, 4 March 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:54, 12 June 2018 (UTC)
  
::::::: Fine with me -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 18:13, 4 March 2018 (UTC)
+
::: I went back to the old wording until a different suggestion is made. I did change "unsupported" to "potentially harmful", see [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=525696&oldid=525688]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:14, 12 June 2018 (UTC)
  
:::::::: "Expert judgement" is vague and subjective. You probably want to define some explicit criteria (even if they are skewed) so helpers can be judged against the same baseline. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 20:15, 4 March 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. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 00:52, 12 June 2018 (UTC)
  
::::::::: The red column should be easy, i.e. "Projects that were abandoned by the author, in favor of a different project or otherwise" with some explanative link for each entry. Yellow could be when long-standing issues are not addressed. That leaves some edge cases, like when a project has frequent commits but issues are not addressed, but in general you'd give other entries a Yes. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:02, 4 March 2018 (UTC)
+
::: Except when pikaur fails in the middle or makes some other mistake, as I pointed out in [https://github.com/actionless/pikaur/issues/201]. Missing the point once again. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:38, 12 June 2018 (UTC)
  
:::::::::: Here's an attempt: A project is "active" if 1/ it isn't officially discontinued/unmaintained, 2/ has a main regular contributor (generally the main author), with some commits of his own at least the past 6 months (in contrast to punctual contributors that work on unimportant issues), 3/ important issues of security and clean build are being actively worked on (commit being pushed or interest in doing so displayed in the past 6 months). That should cover the edge-cases. The proposed duration can be adjusted, ie. ~3 months could be more adequate. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 08:43, 5 March 2018 (UTC)
+
=== <s>Proposal</s> ===
  
::::::::::: Sounds ok to me. I'd probably stick to 6 months or more, otherwise projects like Aura which are more reliable since last year would be immediately classified as "inactive". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:13, 5 March 2018 (UTC)
+
I suggest implementing this comment: [https://github.com/actionless/pikaur/issues/201#issuecomment-396311738], i.e.:
 +
:do not separate commands
 +
to
 +
:do not separate commands or their actions
 +
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:03, 12 June 2018 (UTC)
  
:::::::::::: Proposal: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512792&oldid=512790] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:26, 5 March 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 {{ic|Y}} or {{ic|N}}, there is no modification of the requested pacman action. So I don't think pikaur separates pacman actions. -- [[User:SpineEyE|SpineEyE]] ([[User talk:SpineEyE|talk]]) 14:05, 12 June 2018 (UTC)
:::::::::::: Concerning "general activity" and Rdeckard's comment on "feature complete" helpers, perhaps this could include issue tracking or author reponse (assuming the other criteria are fulfilled). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:29, 5 March 2018 (UTC)
 
  
::::::::::::: I'd put the maintenance column in the front to make helper selection more straightforward, but otherwise LGTM. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 17:05, 5 March 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 [https://github.com/actionless/pikaur/issues/201]. 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:13, 12 June 2018 (UTC)
  
:::::::::::::: Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512818&oldid=512800] cheers -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 5 March 2018 (UTC)
+
:: see: https://github.com/actionless/pikaur/issues/210 - clearly underlines the problem, even if this specific bug gets fixed, the problems itself remain. guess Actionless himself has proven now, that this is not a good idea and should never get a green entry in the "native pacman" column. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 23:02, 12 June 2018 (UTC)
  
== Default sorting for entries ==
+
::: The bug here was that pikaur didn't detect the update, which is of course a faux pas, but not a reason why a wrapper is harmful. I could have just used pacman to circumvent this bug that's now fixed. -- [[User:SpineEyE|SpineEyE]] ([[User talk:SpineEyE|talk]]) 08:35, 13 June 2018 (UTC)
  
Right now, entries are sorted alphabetically and can be sorted by column by clicking on the respective arrows. I propose to make the default sorting both alphabetically and by "less crap", so people don't have to wade through mixes of red and green. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:45, 5 March 2018 (UTC)
+
:::: Imagine it doesn't detect the update to a critical package like bash or openssl and you don't happen to notice it. Your system is then hosed because a helper tries to offer a percieved improvement in UI. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:10, 13 June 2018 (UTC)
  
: Agree, but is this possible to sort by default? See [https://www.mediawiki.org/wiki/Help:Sorting#Sorting_rows_of_a_table MediaWiki] doc. I get a nice result by clicking twice on each column, starting from the last to the first one ("git clone" to "maintenance"). -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 00:35, 6 March 2018 (UTC)
+
:::: One needs to also point out, that you ran "-Syu" but only "-Sy" had been effectively executed, well, and that's what this whole thing was about in the first place. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 12:52, 13 June 2018 (UTC)
  
:: It appears this has to be done manually: [[w:Help:Sorting#Initial_sort_order_of_rows]]. I do like the proposed order. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:19, 8 March 2018 (UTC)
+
: Anyway - let's get back to the point. I'd say `do not separate commands or their actions` is fine, but as another addition I propose: `do not suppress or force pacman behavior by using anything besides native pacman flags, e. g. by altering stdin, stdout.` one may leave out the e.g., but the wording should assure no further missunderstanding [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 13:21, 13 June 2018 (UTC)
  
== "AUR repo diff" ==
+
:: First things first: This is no pikaur bashing, but I really think pikaur currently deserves a "red" entry in the native pacman column. We have not cleary defined what "partially deviates from the given criteria" means, but this weird pacman wrapping with altering stdin and stdout, which has led to more than one problem by now, really is more than "partially" in my opinion. Actionless really created a completely new way of communication between pacman and the user, even though his intentions may be good, he only added a complete new layer of possible failure. see e.g. https://github.com/actionless/pikaur/issues/201#issuecomment-396292082 or https://github.com/actionless/pikaur/issues/210 . if we append the proposed wording of mine, `do not suppress or force pacman behavior by using anything besides native pacman flags`, it really is more than partially deviating. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 13:37, 13 June 2018 (UTC)
  
[https://wiki.archlinux.org/index.php?title=AUR_helpers&curid=4748&diff=512978&oldid=512964] no idea what that's supposed to mean. If it's git diffs, half of the table supports those. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:59, 8 March 2018 (UTC)
+
::: I'm not sure on the exact wording (or if this will cover all future cases of hacking around pacman) but I agree that issues like those you describe warrant a red entry. Maybe we can put it in a third bullet, <s>a helper going against two bullets clearly doesn't classify as "partial" in the relevant criteria.</s>
 +
::: If we make the change I'd also change yay to Red in native pacman until #490 is resolved, so that we don't get more complaints on "unfair treatment". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:21, 13 June 2018 (UTC)
  
: yup, that means exactly that. i wasn't sure if it worth mentioning or not [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:24, 8 March 2018 (UTC)
+
:::: Regarding the wording: I agree, that there will always be possibilites to misuse the wording, but in that case we may simply change the wording again. It's not like we have to cover thousands of AUR Helpers. At least I cannot currently think of a way to misuse the wording, if we append `do not separate commands or their actions` and `do not suppress or force pacman behavior by using anything besides native pacman flags.`. regarding the red entries: I agree also, that yay should get a red entry by now, since it would be not fair otherwise. but since Morganamilo already responded, that they are going to fix the problem, that should not be that big of a deal [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 14:30, 13 June 2018 (UTC)
  
:: when a helper supports git clone but not git diff, we could consider using [[Template:Y]] instead of [[Template:Yes]] for the git column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:58, 8 March 2018 (UTC)
+
:::::Up to you what you do, If you're being kind you could offer me the same week trizen got for split packages. The y u split is actually fixed in my tree already by the way. Need to push Jguer for a release. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 14:40, 13 June 2018 (UTC)
  
::: good idea [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:59, 8 March 2018 (UTC)
+
:::::: In that case I propose to wait 1/2 weeks until updating the criteria / pikaur colors too. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:43, 13 June 2018 (UTC)
 +
 
 +
::::::: I guess the criteria should be updated now, so that they are "official". But waiting with changing the colors seems fine. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 14:55, 13 June 2018 (UTC)
 +
 
 +
:::::::: With [https://github.com/actionless/pikaur/issues/201#issuecomment-397419219] where the author clearly states that he plans to deliberately circumvent the new criteria, is the added complexity worth it? I propose to continue discussion in the now re-opened [[Talk:AUR_helpers#Add_back_pikaur]] instead, this whole discussion has become a huge time sink with no further prospect at improvement. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:37, 14 June 2018 (UTC)
 +
 
 +
:::::::: With comments like [https://github.com/actionless/pikaur/issues/201#issuecomment-396993764] it's clear that pikaur no longer deserves any generosity on our or the wiki's part, so let's the change the color after all. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:37, 13 June 2018 (UTC)
 +
 
 +
::::: Sounds reasonable to me, I'll make the changes unless there's further opinions -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:37, 13 June 2018 (UTC)
 +
 
 +
::::: Just to add another reference for those looking at this discussion, ''pakku'' also has a Partial/yellow entry for pacman wrap yet it has never had the issues we're describing (or not that I know of) and it furthermore specifically made the steps between -Sy and -Su to not fail. If that's partial then anything more invasive / prone to failure than that should definitely be red. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:36, 13 June 2018 (UTC)
 +
 
 +
::::::I became a little curious. As I described on my wiki page, I split commands only to make {{ic|-Syu repopackage aurpackage}} work better (in my opinion): {{ic|-Sy}} + {{ic|-Su repopackage}} + install {{ic|aurpackage}} from AUR. But in case of simple {{ic|-Syu}} I can actually just do {{ic|-Syu}} and check installed AUR packages later, since there are no targets provided and I don't need to check something ''right now''. Will it deserve green entry then? Not that I'm too concerned about it, I just came up with the idea of making this (definitely the most common) case safer. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 15:34, 13 June 2018 (UTC)
 +
 
 +
::::::: I think the best approach is having an optional flag or config option where the user can decide to split -Syu. But what you describe is something I guess. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:53, 13 June 2018 (UTC)
 +
 
 +
=== Proposal summary ===
 +
 
 +
: do not separate commands ''or their actions''
 +
: do not suppress or force pacman behavior by using anything besides native pacman flags, e. g. by altering stdin, stdout
 +
or (proposed in issue #201)
 +
: do not modify the pacman prompt
 +
 
 +
Latter might be overly broad as it includes --noconfirm, but it might make sense when adding "by default". Note: --ask "modifies" the prompt in the sense that it reverses it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:00, 15 June 2018 (UTC)
 +
 
 +
== <s>Relax batch interaction criteria</s> ==
 +
 
 +
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: [https://github.com/actionless/pikaur/issues/201]
 +
 
 +
Therefore I propose to remove the second bullet from batch interaction and perhaps include {{ic|--ask}} as a potentially harmful command in ''Native pacman''. -- [[User:Alad|Alad]] ([[User talk: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. [[User:Morganamilo|Morganamilo]] ([[User talk: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. [[User:Polygamma|Polygamma]] ([[User talk: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 {{ic|pacinstall --remove}} would be problematic for the same reasons) -- [[User:Alad|Alad]] ([[User talk: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. [[User:Morganamilo|Morganamilo]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk: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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 16:49, 12 June 2018 (UTC)
 +
 
 +
::::::If we decide it's not as harmful it probably doesn't make sense to pack it in the same sentence as -Ud/-Rdd. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:33, 12 June 2018 (UTC)
 +
 
 +
::::::I guess not everyone will catch that a package depends on foo-git explicitely rather than foo, for example. I also wonder how --ask behaves with regard to {{ic|replaces}}, which is often misused on the AUR. Bottom-line quantifying to what extent potentially harmful commands are indeed harmful is pretty difficult... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:58, 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. [[User:Polygamma|Polygamma]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk: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. [[User:Polygamma|Polygamma]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:47, 12 June 2018 (UTC)
 +
 
 +
::::::: I think the main problem is, that we are trying to narrow down very complex problems to single colors in a wiki table. All in all the table should give an overview for users who want to choose an AUR Helper. Maybe one should accept, that it could a better approach to link to the READMEs of the AUR Helpers explaining what they do in those cases? e.g. in case of aurman: Description of the config option for --ask=4 and the description of `--do_everything` [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 16:52, 12 June 2018 (UTC)
 +
 
 +
:::::::: Okay how about we do that and remove the colors from the Batch interaction column? Then every user can decide if the trade-off of using potentially dangerous options for batch interaction is worth it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:55, 12 June 2018 (UTC)
 +
 
 +
::::::::: I guess that's a fairer option. Every dev of an AUR Helper may decide in which depth he explains those features, naming pros and cons etc. as long as it is technically true. Users then have to read a bit from now on, which should be encouraged anyway. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:00, 12 June 2018 (UTC)
 +
 
 +
:::::::::Sure but I think the description of native pacman should probably be explained more thoroughly on the page with the pro's and cons. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 16:57, 12 June 2018 (UTC)
 +
 
 +
::::::::::That's fine by me. If pacutils works as I described above we can also mention it including the potential downside of it not being pacman. Or just leave that to AUR helper readmes. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:01, 12 June 2018 (UTC)
 +
 
 +
::::::::::: Is there even an AUR Helper currently using pacutils? If not, that would be quite redundant? [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:02, 12 June 2018 (UTC)
 +
 
 +
:::::::::::: I planned to at least take a look at it for aurutils... but no. It could be useful to people writing new helpers though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:03, 12 June 2018 (UTC)
 +
:::::::::::: edit: assuming you mean pacinstall. Both trizen and aurutils depend on pacutils already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:03, 12 June 2018 (UTC)
 +
 
 +
::::::::::::: yeah, sorry, i mean pacinstall specifically [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:05, 12 June 2018 (UTC)
 +
 
 +
:::::::::::::: I guess we can ignore {{ic|pacinstall}} until someone figures out how it works exactly and/or implements it in their helper. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:06, 12 June 2018 (UTC)
 +
 
 +
::::::::::::::: sounds great. those changes should make the table even better. btw: thanks for your work, alad. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:07, 12 June 2018 (UTC)
 +
 
 +
: This should be an ideal place where can expand on the harmful commands: [[System_maintenance#Avoid_certain_pacman_commands]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:11, 13 June 2018 (UTC)
 +
 
 +
:: I flagged the section for expansion. With that I think the last topic in this discussion (and pikaur#201) has been handled, thanks for all the input -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:52, 13 June 2018 (UTC)
 +
 
 +
=== <s>optional vs. non-default</s> ===
 +
 
 +
Isn't non-default the same as optional? [https://wiki.archlinux.org/index.php?title=AUR_helpers&curid=4748&diff=525942&oldid=525917] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:24, 13 June 2018 (UTC)
 +
 
 +
: I do not think so. A setting could be optional and default, if it is enabled by default, but I may turn it off. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 14:32, 13 June 2018 (UTC)
 +
 
 +
::Yep I had this confusion when first looking at the table. I had no idea optional meant off by default and couldn't stop thinking, "why is optional yellow? Surely a choice is even better than a yes". [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 14:34, 13 June 2018 (UTC)
 +
 
 +
::: How about we make this explicit by saying something like "has to be enabled specifically by the user" -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:38, 13 June 2018 (UTC)
 +
 
 +
:::: sounds good. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 14:39, 13 June 2018 (UTC)
 +
 
 +
::::: done -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:51, 13 June 2018 (UTC)

Latest revision as of 17:01, 16 June 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)

pikaur

Due to conflicting and non-resolvable opinions regarding how pikaurAUR handles the Native pacman column (see [1]) as well as lacking documentation about the project in general, this helper was moved from the main AUR helpers article to its discussion page.

In the unlikely event that both of these issues are addressed, the entry may be moved back to the article. -- Alad (talk) 09:09, 15 June 2018 (UTC)

Name Written In Secure Clean build Native pacman Reliable parser Reliable solver Split packages Git clone Diff view Batch interaction Shell completion Specificity
pikaurAUR Python Yes Yes Partial Yes Yes Yes Yes Yes 1, 2, 3 bash, fish, zsh dynamic users, multilingual, sort by votes/popularity, print news

"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 [2] 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: [3] -- 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 [4]). 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 [5], 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)

trizen and split packages

Trizen no longer works with split packages since pacman 5.1: [6] 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)
[7] -- Alad (talk) 09:01, 15 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: https://github.com/actionless/pikaur/issues/201#issuecomment-395962657 - 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)
I'd like to reopen this discussion, and point out all the answers found here: https://github.com/actionless/pikaur/issues/201 One really has to discuss, what to do with pikaur from now on, regarding the table in the wiki. I surely can only speak for myself, but I am not interested in validating the technical claims made by Actionless regarding pikaur, to ensure, that it is really doing what he claims it to be doing. Since the table should give a technical overview, that has to be done, and I am not sure, if anyone else is willing to do this, after this discussion. Polygamma (talk) 20:15, 14 June 2018 (UTC)
As I pointed out in #Proposal I'm definitely done with investing any more time in this. After 200 comments on github I thought to have found a satisfactory solution, then out of the blue the pikaur author started making preposterous remarks on other helper authors with no technical value or relevance whatsoever. Since furthermore the project is in constant shift and no real documentation is given, expecting to keep such entry updated is beyond reasonable. Unless there's volounteers I suggest to remove the entry again and leave some notice similar to what's done in Bitcoin#Bitcoin software. -- Alad (talk) 20:46, 14 June 2018 (UTC)
I have a better idea: move the pikaur entry to the discussion with an appropriate note. -- Alad (talk) 08:57, 15 June 2018 (UTC)
Done, closing. -- Alad (talk) 09:10, 15 June 2018 (UTC)
You might go even further and more to the point. Consider changing the note in AUR helpers#Build and search to something like this:
Note: The content of this section is peer-reviewed and modifications require a discussion in Talk:AUR helpers. Furthermore, to avoid unreasonable competition and abuse of the specified criteria to get "greener" results, only projects whose development is driven by purely technical arguments can be listed in the tables.
I'm not sure if the motivation is understandable by just reading the note, maybe you can come up with something better. -- Lahwaacz (talk) 21:50, 15 June 2018 (UTC)
This is a bit over the top. New wording would imply that something bad like this already happened and to be expected to happen again in the future. Worst case scenario of resolving original topic that I opened already happened and I regret taking any part in it. There is no reason to push narratives even further. I want this misunderstanding to end and be forgotten not engraved into Draconian laws. -- Svito (talk) 22:26, 15 June 2018 (UTC)
I agree that this is an exceptional case only so I don't think stricter notes/wordings are necessary. -- Alad (talk) 12:16, 16 June 2018 (UTC)
I agree, that going further would be too much. But I've got one question to @Svito - Why do you think, that this is only a "misunderstanding"? And at which point? Polygamma (talk) 17:01, 16 June 2018 (UTC)

Native pacman criteria and IO manipulation

pikaur

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)

Proposal

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

do not separate commands

to

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)
see: https://github.com/actionless/pikaur/issues/210 - clearly underlines the problem, even if this specific bug gets fixed, the problems itself remain. guess Actionless himself has proven now, that this is not a good idea and should never get a green entry in the "native pacman" column. Polygamma (talk) 23:02, 12 June 2018 (UTC)
The bug here was that pikaur didn't detect the update, which is of course a faux pas, but not a reason why a wrapper is harmful. I could have just used pacman to circumvent this bug that's now fixed. -- SpineEyE (talk) 08:35, 13 June 2018 (UTC)
Imagine it doesn't detect the update to a critical package like bash or openssl and you don't happen to notice it. Your system is then hosed because a helper tries to offer a percieved improvement in UI. -- Alad (talk) 10:10, 13 June 2018 (UTC)
One needs to also point out, that you ran "-Syu" but only "-Sy" had been effectively executed, well, and that's what this whole thing was about in the first place. Polygamma (talk) 12:52, 13 June 2018 (UTC)
Anyway - let's get back to the point. I'd say `do not separate commands or their actions` is fine, but as another addition I propose: `do not suppress or force pacman behavior by using anything besides native pacman flags, e. g. by altering stdin, stdout.` one may leave out the e.g., but the wording should assure no further missunderstanding Polygamma (talk) 13:21, 13 June 2018 (UTC)
First things first: This is no pikaur bashing, but I really think pikaur currently deserves a "red" entry in the native pacman column. We have not cleary defined what "partially deviates from the given criteria" means, but this weird pacman wrapping with altering stdin and stdout, which has led to more than one problem by now, really is more than "partially" in my opinion. Actionless really created a completely new way of communication between pacman and the user, even though his intentions may be good, he only added a complete new layer of possible failure. see e.g. https://github.com/actionless/pikaur/issues/201#issuecomment-396292082 or https://github.com/actionless/pikaur/issues/210 . if we append the proposed wording of mine, `do not suppress or force pacman behavior by using anything besides native pacman flags`, it really is more than partially deviating. Polygamma (talk) 13:37, 13 June 2018 (UTC)
I'm not sure on the exact wording (or if this will cover all future cases of hacking around pacman) but I agree that issues like those you describe warrant a red entry. Maybe we can put it in a third bullet, a helper going against two bullets clearly doesn't classify as "partial" in the relevant criteria.
If we make the change I'd also change yay to Red in native pacman until #490 is resolved, so that we don't get more complaints on "unfair treatment". -- Alad (talk) 14:21, 13 June 2018 (UTC)
Regarding the wording: I agree, that there will always be possibilites to misuse the wording, but in that case we may simply change the wording again. It's not like we have to cover thousands of AUR Helpers. At least I cannot currently think of a way to misuse the wording, if we append `do not separate commands or their actions` and `do not suppress or force pacman behavior by using anything besides native pacman flags.`. regarding the red entries: I agree also, that yay should get a red entry by now, since it would be not fair otherwise. but since Morganamilo already responded, that they are going to fix the problem, that should not be that big of a deal Polygamma (talk) 14:30, 13 June 2018 (UTC)
Up to you what you do, If you're being kind you could offer me the same week trizen got for split packages. The y u split is actually fixed in my tree already by the way. Need to push Jguer for a release. Morganamilo (talk) 14:40, 13 June 2018 (UTC)
In that case I propose to wait 1/2 weeks until updating the criteria / pikaur colors too. -- Alad (talk) 14:43, 13 June 2018 (UTC)
I guess the criteria should be updated now, so that they are "official". But waiting with changing the colors seems fine. Polygamma (talk) 14:55, 13 June 2018 (UTC)
With [22] where the author clearly states that he plans to deliberately circumvent the new criteria, is the added complexity worth it? I propose to continue discussion in the now re-opened Talk:AUR_helpers#Add_back_pikaur instead, this whole discussion has become a huge time sink with no further prospect at improvement. -- Alad (talk) 20:37, 14 June 2018 (UTC)
With comments like [23] it's clear that pikaur no longer deserves any generosity on our or the wiki's part, so let's the change the color after all. -- Alad (talk) 16:37, 13 June 2018 (UTC)
Sounds reasonable to me, I'll make the changes unless there's further opinions -- Alad (talk) 14:37, 13 June 2018 (UTC)
Just to add another reference for those looking at this discussion, pakku also has a Partial/yellow entry for pacman wrap yet it has never had the issues we're describing (or not that I know of) and it furthermore specifically made the steps between -Sy and -Su to not fail. If that's partial then anything more invasive / prone to failure than that should definitely be red. -- Alad (talk) 14:36, 13 June 2018 (UTC)
I became a little curious. As I described on my wiki page, I split commands only to make -Syu repopackage aurpackage work better (in my opinion): -Sy + -Su repopackage + install aurpackage from AUR. But in case of simple -Syu I can actually just do -Syu and check installed AUR packages later, since there are no targets provided and I don't need to check something right now. Will it deserve green entry then? Not that I'm too concerned about it, I just came up with the idea of making this (definitely the most common) case safer. Kitsunyan (talk) 15:34, 13 June 2018 (UTC)
I think the best approach is having an optional flag or config option where the user can decide to split -Syu. But what you describe is something I guess. -- Alad (talk) 16:53, 13 June 2018 (UTC)

Proposal summary

do not separate commands or their actions
do not suppress or force pacman behavior by using anything besides native pacman flags, e. g. by altering stdin, stdout

or (proposed in issue #201)

do not modify the pacman prompt

Latter might be overly broad as it includes --noconfirm, but it might make sense when adding "by default". Note: --ask "modifies" the prompt in the sense that it reverses it. -- Alad (talk) 09:00, 15 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: [24]

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)
If we decide it's not as harmful it probably doesn't make sense to pack it in the same sentence as -Ud/-Rdd. -- Alad (talk) 17:33, 12 June 2018 (UTC)
I guess not everyone will catch that a package depends on foo-git explicitely rather than foo, for example. I also wonder how --ask behaves with regard to replaces, which is often misused on the AUR. Bottom-line quantifying to what extent potentially harmful commands are indeed harmful is pretty difficult... -- Alad (talk) 16:58, 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)
I think the main problem is, that we are trying to narrow down very complex problems to single colors in a wiki table. All in all the table should give an overview for users who want to choose an AUR Helper. Maybe one should accept, that it could a better approach to link to the READMEs of the AUR Helpers explaining what they do in those cases? e.g. in case of aurman: Description of the config option for --ask=4 and the description of `--do_everything` Polygamma (talk) 16:52, 12 June 2018 (UTC)
Okay how about we do that and remove the colors from the Batch interaction column? Then every user can decide if the trade-off of using potentially dangerous options for batch interaction is worth it. -- Alad (talk) 16:55, 12 June 2018 (UTC)
I guess that's a fairer option. Every dev of an AUR Helper may decide in which depth he explains those features, naming pros and cons etc. as long as it is technically true. Users then have to read a bit from now on, which should be encouraged anyway. Polygamma (talk) 17:00, 12 June 2018 (UTC)
Sure but I think the description of native pacman should probably be explained more thoroughly on the page with the pro's and cons. Morganamilo (talk) 16:57, 12 June 2018 (UTC)
That's fine by me. If pacutils works as I described above we can also mention it including the potential downside of it not being pacman. Or just leave that to AUR helper readmes. -- Alad (talk) 17:01, 12 June 2018 (UTC)
Is there even an AUR Helper currently using pacutils? If not, that would be quite redundant? Polygamma (talk) 17:02, 12 June 2018 (UTC)
I planned to at least take a look at it for aurutils... but no. It could be useful to people writing new helpers though. -- Alad (talk) 17:03, 12 June 2018 (UTC)
edit: assuming you mean pacinstall. Both trizen and aurutils depend on pacutils already. -- Alad (talk) 17:03, 12 June 2018 (UTC)
yeah, sorry, i mean pacinstall specifically Polygamma (talk) 17:05, 12 June 2018 (UTC)
I guess we can ignore pacinstall until someone figures out how it works exactly and/or implements it in their helper. -- Alad (talk) 17:06, 12 June 2018 (UTC)
sounds great. those changes should make the table even better. btw: thanks for your work, alad. Polygamma (talk) 17:07, 12 June 2018 (UTC)
This should be an ideal place where can expand on the harmful commands: System_maintenance#Avoid_certain_pacman_commands -- Alad (talk) 10:11, 13 June 2018 (UTC)
I flagged the section for expansion. With that I think the last topic in this discussion (and pikaur#201) has been handled, thanks for all the input -- Alad (talk) 14:52, 13 June 2018 (UTC)

optional vs. non-default

Isn't non-default the same as optional? [25] -- Alad (talk) 14:24, 13 June 2018 (UTC)

I do not think so. A setting could be optional and default, if it is enabled by default, but I may turn it off. Polygamma (talk) 14:32, 13 June 2018 (UTC)
Yep I had this confusion when first looking at the table. I had no idea optional meant off by default and couldn't stop thinking, "why is optional yellow? Surely a choice is even better than a yes". Morganamilo (talk) 14:34, 13 June 2018 (UTC)
How about we make this explicit by saying something like "has to be enabled specifically by the user" -- Alad (talk) 14:38, 13 June 2018 (UTC)
sounds good. Polygamma (talk) 14:39, 13 June 2018 (UTC)
done -- Alad (talk) 14:51, 13 June 2018 (UTC)