Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(pikaur claims to no longer split -Syu: rm closed)
(pikaur: rm closed)
Line 101: Line 101:
  
 
== Native pacman criteria and IO manipulation ==
 
== Native pacman criteria and IO manipulation ==
 
=== <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.
 
 
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
 
 
-- [[User:Svito|Svito]] ([[User talk: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 [[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)
 
 
:: [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)
 
 
:: 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)
 
 
::: 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)
 
 
::: 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)
 
 
:: 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)
 
 
::: 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)
 
  
 
=== <s>Proposal</s> ===
 
=== <s>Proposal</s> ===

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

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)

Add pacui to the table?

[8] 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. [9]) 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 ([10] 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 [11] and [12], 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 [13] 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: [14] -- 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, and regardless if by users or staff. -- Alad (talk) 09:52, 19 June 2018 (UTC)

Native pacman criteria and IO manipulation

Proposal

I suggest implementing this comment: [15], 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 [16]. 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 [17] 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 [18] 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)