Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(`Reliable solver` discussion: pikaur update)
(Required package update frequency: help on signing comments, use of header to quickly distinguish topics, and lists)
 
(391 intermediate revisions by 16 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> ==
  
== <s>Unmaintained Aur Helpers</s> ==
+
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)
  
It seems my edit to adding the info about Pacaur being unmaintained was reverted. Are we not allowed to mark aur helpers as unmaintained? What is the proper way to go about letting users know that things like Pacaur are now unmaintained upstream?[https://github.com/rmarquis/pacaur] {{unsigned|19:33, 18 December 2017‎|Ase1590}}
+
: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)
  
:Unmaintained helpers are not a big deal since helpers should only be used by people who can solve their own problems (as indicated by the warning at the top of the article). However, if you can demonstrate that a helper ''actually stops working'' in a general sense, with no community interest to fix it, you can remove them from the article. (and file a request on AUR as well) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:43, 18 December 2017 (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. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 12:15, 9 June 2018 (UTC)
  
::I would argue that an [unmaintained] tag would be helpful for quickly finding an AUR helper instead of having to futz around on github pages to see that it has not be updated in X amount of months/years and that it has been abandoned. I agree that if an aur helper ''actually'' broke due to some update, that it would be a candidate for removal from the AUR helper page. The whole point of wiki info is for at-glance quick info, otherwise, it'd be documentation and not a wiki. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 18:59, 18 December 2017 (UTC)
+
:::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)
  
:::That brings other issues. First, you'd have to make a reasonable definition of "unmaintained". Should it be an official statement from the maintainer where he distances himself from the project? Should it be some fixed interval between commits? Should it be how upstream cares for outstanding issues? If you include the last two criteria, 90% of the AUR helpers on this page classifies as "unmaintained" and the value of the tag is lost.
+
:::: [https://github.com/trizen/trizen/commit/f0a9dfe408d41117c11c364ed98796eeca9b35c2] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:01, 15 June 2018 (UTC)
:::Second, the "unmaintained" information would have to be continually checked to keep the page factual, which for 23 helpers in [[AUR helpers#Build and search]] alone is hardly reasonable. Especially when you as the user already has a nice table at the bottom, which narrows down your choice to 3-4 projects (entries with all the green) already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:14, 18 December 2017 (UTC)
 
  
::::I think we can use your first definition of unmaintained as the formal definition for this page. The developer of Pacaur has made an official statement where he is distancing himself. As for the second point, the "continually checked" argument does not make sense for a wiki, as users are free to edit and update information whenever. All wiki pages can be subject to information rot, just look at some of the less common non-english pages in the arch wiki, which have in one instance in IRC displayed information about configuring arch prior to Systemd integration. Wikis stay up to date so long as other users contribute. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:29, 18 December 2017 (UTC)
+
== Add pacui to the table? ==
  
:::::It still makes no sense to me as it punishes projects for maintainers declaring them as unmaintained. Other projects could make no such announcement and be left in a far worse state, yet as they would not be marked as "unmaintained", would be prioritized in their consideration. (which again, is not deserved) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:32, 18 December 2017 (UTC)
+
[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 suppose we could add a softer toned tag such as [project maintainer needed] that way this instead encourages people to pick it up upstream when reading. Formally abandoned packages are going to lose support over time anyway from social media like reddit and those subscribed to the project via things like github, and it can't be helped (especially if the package outright becomes broken/incompatible). [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:41, 18 December 2017 (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)
  
::::::: That's a notion I can support. I'm not sure on the best format to add such a tag to the page. It seems out of place in the "Specificity" column of the comparison table (since it's not a feature of the project); on the other hand, it's more in plain view there and e.g. aura already mentions an aspect not strictly feature-related (the need for ArchHaskell). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:51, 18 December 2017 (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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 12:37, 11 June 2018 (UTC)
  
:::::::: How about [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=503126&oldid=503125] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:57, 18 December 2017 (UTC)
+
== <s>Add back pikaur</s> ==
  
::::::::: I like this, though it might look more pleasing if it were moved under the Build and Search heading at the end of the pacaur description, though that ''could'' just be my OCD just kicking in. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 20:06, 18 December 2017 (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.
  
:::::::::: Feel free to make the change. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:13, 18 December 2017 (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.
  
::::::::::: After thinking about it, I think yours is best. Most attention will be focused on the table as you said earlier, so if the aim is to attract new contributers to a project then it makes most sense for it to be in the highest visibility area, which in this case is the comparison table -- 21:19, 18 December 2017‎ Ase1590
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:49, 11 June 2018 (UTC)
  
== Reliable solver  ==
+
: 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)
  
https://aur.archlinux.org/packages/plasma-git-meta/ have some missing dependencies:
+
: @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)
  discover-git
+
:: 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):
  oxygen-git
 
  
Which other package can I use to test the criteria of being a reliable solver?
+
: 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)
[[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
  
:Try plasma-desktop-git or ros-indigo-desktop. I tried testing it myself but couldn't since pkaur failed immediately with a python traceback. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 5 February 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)
  
:: `ros-indigo-desktop` failed because it depends on https://aur.archlinux.org/packages/ros-indigo-catkin/ which depends on `python2-catkin-pkg` (which provided by https://aur.archlinux.org/packages/python2-catkin_pkg/). However AUR RPC seems to be not supports search by Provides field:
+
::: 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)
:: https://aur.archlinux.org/rpc/?v=5&type=search&arg=python2-catkin-pkg&by=name-desc
 
:: https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=python2-catkin-pkg
 
  
:: For `plasma-desktop-git` i've got dependencies resolved (hopefully correctly):  
+
:::: 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)
:: https://imgur.com/a/9dA5S however it's gonna build for month or so on my hardware. Mb there is some way to reproduce it with some simpler example? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
  
::: Also could you please upload the traceback somewhere? It's probably unrelated to resolving but still will be useful for me. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:32, 5 February 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)
  
::::[https://paste.xinu.at/Kn7s/] [https://paste.xinu.at/w7Gud/] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 6 February 2018 (UTC)
+
:::::: Done, closing. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:10, 15 June 2018 (UTC)
  
::::: thanks! and what is the output of `file /var/lib/pacman/sync/custom.db`? i have idea how to fix that but first i am trying to understand if .db file is always gzip or its format could vary
+
::::::: 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)
  
::::: also dependencies list for plasma got computed the same (in pikaur some of deps were duplicated but i've fixed that already) [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 21:14, 6 February 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. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:26, 15 June 2018 (UTC)
  
::::::The database files can also be ''xz'' or any other format that ''bsdtar'' supports. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:39, 6 February 2018 (UTC)
+
:::::::::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)
  
::::::: Thanks, i've update it to use `bsdtar` instead of `gzip`, and also added some error handling to that stage. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 23:57, 6 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)
 +
 
 +
::::::::::That is not exactly what I said. I do not fully appreciate being asked a public response in a closed thread.
 +
::::::::::I think it is fair to say (and I checked on this privately) that there was a misunderstanding of the issue from [[User:Actionless|Actionless]]' side when this begun escalating. Unfortunately for him he was clueless in this social situation which may be possible result of different cultural exposure as well as lack of social experience on his side. I cannot blame him for being human and making mistakes provided he is willing to learn from them and improve as an individual in order to bring benefit to himself and others.
 +
::::::::::When I opened this issue I asked everybody to try not taking this issue too personally. Having prejudice against somebody just makes you hate that character in your head when in reality he is just like you but born and learned differently.
 +
::::::::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:07, 19 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:52, 19 June 2018 (UTC)
 +
 
 +
== Native pacman criteria and IO manipulation ==
 +
 
 +
=== 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)
 +
 
 +
== Required package update frequency ==
 +
 
 +
How often does a package have to be updated to remain in 'Active'?
 +
 
 +
* '''bauerbill''' - last update: 2017-10-03
 +
* '''aura''' - last update: 2017-10-07
 +
 
 +
{{Unsigned|13:45, 20 June 2018 (UTC)|J1simon}}
 +
 
 +
:There's no criteria for this. There were, but then people would periodically update their README and call it an "update". See: [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&oldid=520747#Effectiveness_of_the_.22inactive.22_table] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:59, 20 June 2018 (UTC)

Latest revision as of 17:44, 20 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)
That is not exactly what I said. I do not fully appreciate being asked a public response in a closed thread.
I think it is fair to say (and I checked on this privately) that there was a misunderstanding of the issue from Actionless' side when this begun escalating. Unfortunately for him he was clueless in this social situation which may be possible result of different cultural exposure as well as lack of social experience on his side. I cannot blame him for being human and making mistakes provided he is willing to learn from them and improve as an individual in order to bring benefit to himself and others.
When I opened this issue I asked everybody to try not taking this issue too personally. Having prejudice against somebody just makes you hate that character in your head when in reality he is just like you but born and learned differently.
-- Svito (talk) 20:07, 19 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 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)

Required package update frequency

How often does a package have to be updated to remain in 'Active'?

  • bauerbill - last update: 2017-10-03
  • aura - last update: 2017-10-07

—This unsigned comment is by J1simon (talk) 13:45, 20 June 2018 (UTC). Please sign your posts with ~~~~!

There's no criteria for this. There were, but then people would periodically update their README and call it an "update". See: [15] -- Alad (talk) 13:59, 20 June 2018 (UTC)