Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(Add back pikaur)
(Add back pikaur: re)
Line 111: Line 111:
::::::::: 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 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)
:::::::::: Apparently misogeny is "just a misunderstanding". I have no interest in pursuing this further here; it should however be clear that such behavior is absolutely not tolerated, be it on ArchWiki or other parts of the Arch community. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:52, 19 June 2018 (UTC)
== Native pacman criteria and IO manipulation ==
== Native pacman criteria and IO manipulation ==

Revision as of 09:52, 19 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)


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)
Apparently misogeny is "just a misunderstanding". I have no interest in pursuing this further here; it should however be clear that such behavior is absolutely not tolerated, be it on ArchWiki or other parts of the Arch community. -- Alad (talk) 09:52, 19 June 2018 (UTC)

Native pacman criteria and IO manipulation


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

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

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

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

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


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

do not separate commands


do not separate commands or their actions

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

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