Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
(→‎Add "pacman wrap" column: all subdiscussions closed)
(answer why pacaur is still supported)
 
(620 intermediate revisions by 32 users not shown)
Line 1: Line 1:
{{Note|'''Moderation''' — If your AUR helper does [[partial upgrade]]s ''without explicit user intervention'' (i.e, specifying {{ic|-Sy}} on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 20 September 2015 (UTC)
+
== Legend editions ==
}}
 
  
== <s>Comparison table - build directory</s> ==
+
[[Special:Diff/573543/573551]]: Good revert, I did these late into sleepless night and did not notice this were huge and not that thought through changes :/
  
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.
+
* <s>Merge note definitions for partial and optional as part of legends list?</s> This was a mistake, note there exactly makes sense according to style rules.
 +
* Add known used unsafe flags to legend, add that asterisk means optional, as it may be unclear?
 +
* Move legend concerning pacman wrappers only inside its section? Alternatively mention these apply only to pacman wrappers, example text:
  
The default values I've garnered so far, assuming TMPDIR is not set:
+
:;Unsafe flags: Potentially harmful pacman flags that could be used by [[#pacman wrappers]].
 +
::* {{ic|--ask}} – [https://git.archlinux.org/pacman.git/commit/src/pacman?id=90e3e02 Undocumented option] to be used for testing only;
 +
::* {{ic|-Sy}} – Can lead to [[partial upgrade]];
 +
::* {{ic|-Ud}} – Skips dependency checks when installing packages.
 +
::{{Note|Asterisk means these pacman flags are optionally enabled.}}
 +
:;Batch interaction: Ability of [[#pacman wrappers]] to prompt before the build process and package transactions, in particular:
 +
::# Combined summary of repository and AUR package upgrades;
 +
::# Resolution of package conflicts and choice of providers.
  
* aurutils: $XDG_CACHE_HOME
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 07:33, 22 May 2019 (UTC)
* pacaur: $XDG_CACHE_HOME (changed from /tmp, see [https://github.com/rmarquis/pacaur/commit/c5d750f75f040b21249fff100a2c8875348d03d1])
 
* bauerbill: $PWD/build
 
* pkgbuilder: $PWD, /tmp when specified with -S
 
* packer: /tmp (TMPDIR)
 
* yaourt: /tmp (yaourtrc)
 
  
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:16, 1 April 2016 (UTC)
+
:Batch interaction isn't specific to pacman wrappers, at least not 2. The legend denotes it as a column though, which it isn't. At the same time, I'm not sure if replacing "columns" with "columns and values" is a good idea.
 +
:If we document all the unsafe flags, I would argue it's out of scope in this article and should be expanded in [[System_maintenance#Avoid_certain_pacman_commands]] instead. (Side-note: what if a regular AUR helper uses an unsafe command to e.g. install dependencies? None of the current entries do, but it's a possible scenario.) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:26, 25 May 2019 (UTC)
  
: 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)
+
::How about expanding the note:
 +
{{Note|
 +
* ''Optional'' means that a feature is available, but only through a command-line argument or configuration option. ''Partial'' means that a feature is not fully implemented, or that it partially deviates from the given criteria.
 +
* ''Batch interaction'' indicates the ability to prompt ''before'' the build process and package transactions. In particular:
 +
:1. Combined summary of repository and AUR package upgrades;
 +
:2. Resolution of package conflicts and choice of providers.}}
 +
::I've looked at [[System_maintenance#Avoid_certain_pacman_commands]] again and it contains all needed detail already, apart from the --ask option which is niche (and linked from in the table where appropriate). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 25 July 2019 (UTC)
  
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
+
== Add yup to Pacman wrappers ==
::: 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).
+
Links:
 +
[https://github.com/ericm/yup github] {{AUR|yup}}
  
::::: It seems all active helpers except {{AUR|pkgbuilder}} and {{AUR|naaman}} (edit: [https://github.com/enckse/naaman/issues/17]) switched to {{ic|$XDG_CACHE_HOME}}, so this discussion has lost relevance. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:01, 24 March 2018 (UTC)
+
Right now yup ticks every box in the 'Pacman Wrappers' table except for 'Split packages'.
 +
It has code completion working mostly in zsh and will soon support bash and fish too.
  
== Reliable Updater ==
+
Pros:
  
Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.
+
It fetches pgp keys for you.
 +
It shows the PKGBUILD before installing by default for security reasons.
 +
It shows far more relevant search results that other AUR helpers on the market.
  
ie:  
+
[[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 14:52, 21 July 2019 (UTC)
Does it handle accurate update status on VCS packages?
 
Does it handle accurate update status when developer fails to update .SCRINFO? https://wiki.archlinux.org/index.php/.SRCINFO
 
  
And any other unmentioned situations. [[User:Cody Learner|Cody Learner]] ([[User talk:Cody Learner|talk]]) 18:49, 22 February 2018 (UTC)
+
:It's another yaourt clone - pretty sure we have enough of those in the table already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:11, 21 July 2019 (UTC)
  
:The second is an issue only pacaur has, by design to "improve metadata on the AUR". It has nothing to do with what an AUR helper should do. The first is at best a specificity, since the AUR has no perception of what a VCS package is. See {{Bug|56602}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:02, 22 February 2018 (UTC)
+
:: Even though it's got tonnes of features that yaourt doesn't have? [[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 20:40, 21 July 2019 (UTC)
  
:: I think the most important here to provide reliable testcase to prove the reliability of updater :-) I would suggest mb creating a repo a with some stub PKGBUILDs which could be used as testcases for criterias in the table. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:19, 22 February 2018 (UTC)
+
::: I would argue the splitting into "packages" is the main distinguish feature - things like an ncurses interface are superficial in my book.
 +
::: Generally speaking, most AUR helpers have turned out to be either vaporware or small variations on existing work. Some recent examples: {{AUR|aurs}}, {{AUR|baph}}, {{AUR|gutaur}}, {{AUR|ram}}, {{AUR|raur-git}}, {{AUR|simpleaur-git}}, {{AUR|vam}}. So let's wait a bit how this projects evolves before adding it to the wiki. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:56, 25 July 2019 (UTC)
  
::: Not sure what a testcase of such would look like, since scoring on the other criteria should guarantee reliable updates apart from some pecularities outlined above.
+
:::: Looks like it's still around after 3 months, so it could be added to the article. Would be nice if someone else than upstream tests the column entries, though. Also don't expect to have "far more relevant search" added, because that could basically mean anything. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:37, 10 September 2019 (UTC)
::: About the second case, it has been suggested before to create some centralized place for testing helpers instead of a few arbitrarily chosen AUR packages. However, since AUR helpers are (by definition) for the AUR, I wonder how you'd go about testing these helpers with an external repository. PKGBUILDs specifically made for testing helpers would not be accepted on AUR anyways as too specific. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:30, 22 February 2018 (UTC)
 
  
:::: And what about adding packages to AUR but with some special prefix in package name (`_stub-package-test-reliable-solver`) and very explicit description ("DON'T INSTALL ME. Stub package intended for testing AUR helpers for 'reliable solver' criteria.") and so on? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 23:53, 22 February 2018 (UTC)
+
== <s>Octopi no longer performs partial upgrades</s> ==
  
::::: Considering AUR helpers are something that's tolerated instead of supported, I doubt such packages explicitely targeting them with no use otherwise would have a long lifetime. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 23 February 2018 (UTC)
+
According to [https://github.com/aarnt/octopi/issues/134#issuecomment-503651475 this] GitHub comment as well as [https://github.com/aarnt/octopi/commit/7a32ba9ea2dab91e243a6362496b14e8fb6ac2b0 this] commit, Octopi no longer does partial upgrades as this page says it does.
  
:::::: See [[#"Reference" implementation]] for an alternative. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:29, 8 March 2018 (UTC)
+
[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:14, 25 July 2019 (UTC)
  
::::::: I would argue this is covered by the new "Pacman wrap" column. That said there's some strange cases (e.g. {{AUR|rakudo}} or {{AUR|nvidia-beta}}) which some helpers can install successfully but fail to update afterward. Usually this involves version requirements (though note {{Bug|54906}}). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:31, 18 March 2018 (UTC)
+
:Thanks: [[Special:Diff/578024]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:46, 25 July 2019 (UTC)
  
== "AUR repo diff" ==
+
== Update information on rua? ==
  
[https://wiki.archlinux.org/index.php?title=AUR_helpers&curid=4748&diff=512978&oldid=512964] no idea what that's supposed to mean. If it's git diffs, half of the table supports those. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:59, 8 March 2018 (UTC)
+
Please update information on RUA helper. "Diff view" and "Split packages" were implemented, as per the linked issues. Also, please add "shellcheck" and "local patch application" to the list of features that the helper has. The second is most probably not unique, the first one is unique I think. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 17:28, 23 August 2019 (UTC)
  
: yup, that means exactly that. i wasn't sure if it worth mentioning or not [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:24, 8 March 2018 (UTC)
+
: To be specific on "split packages" support. I've made another manual test on the latest released version of the helper. 1. Tried to install both clion and clion-jre at the same time. RUA only builds it once (`rua install clion clion-jre`). 2. Requested to install `libc++`, it understands that it only needs to be built once but both packages are installed. 3. When trying to install python2-pyalsaaudio, rua correctly builds pkgbase python-pyalsaaudio, and then installs python2-pyalsaaudio. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 11:31, 26 August 2019 (UTC)
  
:: when a helper supports git clone but not git diff, we could consider using [[Template:Y]] instead of [[Template:Yes]] for the git column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:58, 8 March 2018 (UTC)
+
::First request satisfied with [[Special:Diff/581029]]. Let's wait for opinion on other features. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:57, 26 August 2019 (UTC)
  
::: good idea [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:59, 8 March 2018 (UTC)
+
:::Thanks for actually testing this. Regarding the suggested features: running shellcheck before sourcing the PKGBUILD is trivial. I'm not sure what's meant by "local patch application" - does rua support git rebase with local commits, or does it just not undo local changes in the worktree e.g. through {{ic|git --autostash}}? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:34, 10 September 2019 (UTC)
  
== "Reference" implementation ==
+
:::: Regarding shellcheck. It's not THAT trivial. For example, this is the output of `rua shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/7bcbc5fc6ebf731abc8399988dfb4fef. Compare it to the output of raw `shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/edb08becb9ed7dd558b4c8655b57adec. That being said, `rua shellcheck` is not ideal as well. For example, it will always approach $pkgname as an array, and warn on all usages of the variable that treat it as non-array.
 +
:::: Regarding patch application. It keeps your locally reviewed state in a separate branch. Whenever you're ready to merge upstream, it basically does `git merge upstream/master`. You can drop to shell and do a manual rebase as well if you want, though only merging is streamlined as a built-in action. It is also safe for e.g. aborting the installation, because, unless you manually merge upstream changes yourself, changes won't ever leak into your "accepted" state (local branch). Building without merging upstream/master is forbidden as a foolproof. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 16:12, 12 September 2019 (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.
+
== pacaur is also discontinued ==
  
I propose a minimal reference implementation with the following points:
+
According to the project github and discussion on archlinux forum pacaur is discontinued [[User:C13251|C13251]] ([[User talk:C13251|talk]]) 13:14, 24 October 2019 (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.
+
: I think you are confusing the discontinued repo: https://github.com/rmarquis/pacaur with the fork: https://github.com/rmarquis/pacaur The fork seems pretty much alive. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 13:29, 24 October 2019 (UTC)
* Minimal language constructs in e.g. a scripting language like {{Pkg|dash}}.
 
* Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.
 
 
 
My initial plan was to keep such an implementation in a man page {{ic|aurhelper(7)}} (hosted as part of aurutils), but we can consider including on a sub-page of this article. It could be then linked from the comparison table. Thoughts? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:28, 8 March 2018 (UTC)
 
 
 
: Generally agree with the idea, but I don't think there is a way around a set of PKGBUILDs that could be used to test helpers in a local AUR instance. F.e., I wouldn't define a "reliable" helper that doesn't handle split packages well. Since helpers are tolerated rather than supported, upstream limitations of the AUR might be temporary or permanent, meaning the limitation would actually be in the helper itself (f.e. like regex support). Also, I'd use pseudo code for such a reference as the actual implementation itself doesn't matter, unless you'd like to write a new minimalist helper. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 15:26, 8 March 2018 (UTC)
 
 
 
::Apart from {{Bug|56602}}, I can't think of a case where upstream ''opposed'' removing limitations, even if helpers directly benefited. cf. the regex support discussed in [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004036.html] or the exit codes finally introduced in makepkg 5.1 which made automatic building significantly easier imo. To me it seems that the main reason we have these AUR limations is due to the minimal interest of helper writers in contributing upstream, and upstream itself having different priorities. Not sure why former is the case, the PHP codebase may play part in it - at least it does for me.
 
::You can keep ''dash'' close enough to pseudo-code, I guess less so if you want a complete example rather than exemplary code blocks. For the PKGBUILD set, I use this: [https://github.com/AladW/aurutils-test/blob/master/package.t#L11-L31] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 8 March 2018 (UTC)
 
 
 
::: My understanding is that changes that aren't invasive will be accepted upstream, but otherwise might be rejected (see [https://lists.archlinux.org/pipermail/aur-dev/2018-January/004421.html]). One prominent example that comes to mind is {{Bug|48796}}. It's not really relevant anymore since x86 has been officially dropped, but the solution would involve duplicating DB tables on the server, which isn't trivial to implement/migrate. Many of the feature requests involve non-trivial code change, which is the main reason nobody pushed patches; I dislike PHP but the language itself isn't too hard either. For regex, see the bottom of [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004044.html], which is the follow-up of your link above.
 
::: Your testsuite seems interesting (thanks for the link), but one advantage of having a fixed set of packages is that these packages might be updated and change, making these edge cases difficult to test. This happened quite a few times with my own list of test packages in the past and this was rather annoying. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 20:20, 8 March 2018 (UTC)
 
 
 
== <s>Add "pacman wrap" column</s> ==
 
 
 
=== <s>Draft</s> ===
 
Since we have a Clean build column, I believe we should also have a "Pacman wrap" column that details how helpers wrap pacman (if applicable). A green entry should be reserved to helpers that only use pacman directly, while avoiding potentially harmful commands such as {{ic|pacman -Ud}} or {{ic|pacman -Rdd}}. A yellow entry could be for direct pacman use but including use of latter commands. A red entry would be for reimplementations through libalpm or other means. An N/A (grey) entry is used if no pacman wrapping is done in the first place.
 
 
 
The reasoning for this proposal is that while the table gives a good overview on helper features, it gives no indication whatsoever on potential harmful effects due to reimplementations of pacman. This is already having an effect on the support channels, where at best it makes debugging more difficult (see for example [https://bbs.archlinux.org/viewtopic.php?pid=1772440#p1772440]), and having such a column might encourage future helper writers to avoid making this same mistake. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 02:59, 11 March 2018 (UTC)
 
 
 
: I guess that's actually a good idea, I'd just like to include one more thing. That column should yield details about the behavior of that aur helper when using the helper without non native pacman flags. Surely I have something in mind why I say that: aurman flag --do_everything, which is a non native pacman flag, which is also being described in the readme as not recommended, but which may be used. it changes the behavior of aurman -Syu in the first place, so that would be a candidate for the "non-green" entry, but I bet there are other aur helpers out there, which by default only do sane things, but may be used in another way, when specifying any config options or command line flags. one could go one step further maybe: only if the aur helper specifies those side effects in the readme, man page or whatever, the aur helper gets a "green" entry. hence those side effects may only occur if the user uses a flag, whereas those side effects have been clarified enough [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 15:39, 11 March 2018 (UTC)
 
 
 
:: Updated the table (nearly lost all my changes due to edit conflicts...): [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=514103&oldid=514102] Some notes:
 
::* The source code of ''naaman'' and ''yaourt'' was incomprehensible to me, but yaourt at least parses sync dbs by hand ({{ic|yaourt -Q}}) and separates {{ic|pacman -Syu}} to {{ic|pacman -Sy && <stuff> && pacman -Su}} so it got a red entry.
 
::* ''yay'' got a red entry, see below.
 
::* ''pikaur'' got a red entry due to issues like [https://github.com/actionless/pikaur/issues/65], which while resolved, give no indication that pikaur started using pacman rather than a manual (py)alpm implementation. ''aurman'' got a green entry due to it only replacing ''pacman'' when the {{ic|--do_everything flag}} is passed. Correct me if I'm wrong on either.
 
::* I was gratuitous with the {{ic|N/A}} flag; e.g. ''cower'' uses {{man|3|libalpm}} but it's not used as a ''pacman'' wrapper.
 
::-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:04, 18 March 2018 (UTC)
 
 
 
::: Looking very good! The page is much clearer now. Thanks Alad for the rework. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:10, 19 March 2018 (UTC)
 
 
 
:: Also maybe the column should be renamed to something that better reflects Yes/No entries, like "Native pacman" or such. That or change the Yes/No entries to specific ones such as {{ic|<nowiki>{{R|libalpm}}</nowiki>}}. Former should be simpler, since details can be explained in added links. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:14, 18 March 2018 (UTC)
 
 
 
::: I think it's important to keep in mind the table is supposed to be a quick reference to choose a helper. Looking at the average AUR user, I'm not sure adding such technical details is relevant in that context. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:14, 19 March 2018 (UTC)
 
 
 
::: Also note that {{AUR|PKGBUILDer}} has "Yes" in the pacman wrap column, although it uses {{ic|-F}} for something else than pacman. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:46, 19 March 2018 (UTC)
 
 
 
:::: This seems like an oversight ({{ic|pkgbuilder -F}} was present before {{Pkg|pacman}} v5), so I've opened a ticket here: [https://github.com/Kwpolska/pkgbuilder/issues/56] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:19, 19 March 2018 (UTC)
 
 
 
: If yay -Syu is in fact -Syyu, that sounds more like a "bug" that should be fixed. Has this been reported, or acknowledged and dismissed? [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 13:51, 13 March 2018 (UTC)
 
 
 
:: I'm not sure on the -Syy part, but in general, acknowledged and dismissed: [https://github.com/Jguer/yay/issues/146#issuecomment-365358542] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:58, 18 March 2018 (UTC)
 
 
 
::: Fair enough, I did miss that ticket. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:10, 19 March 2018 (UTC)
 
 
 
=== <s>Unsupported pacman options</s> ===
 
For example in pikaur I do use -Rdd in one place: [https://github.com/actionless/pikaur/blob/master/pikaur/install_cli.py#L649-L650]
 
However I don't know any other possible way to handle the removal of conflicting package before installing its replacement with --noconfirm option.
 
But to avoid the problem on the further steps it's guarded with transaction: [https://github.com/actionless/pikaur/blob/master/pikaur/install_cli.py#L654-L660] so if something will fail that operation will be canceled.
 
Also it's not clear to me if there is any difference between {{ic|pacman -Su}} and {{ic|pacman -S $(pacman -Quq)}}. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 03:56, 11 March 2018 (UTC)
 
 
 
If pacman would have an option to not confirm about installing packages ({{ic|:: Proceed with installation? [Y/n]}}) but confirm everything else (like conflicts and so on) that would actually solve the issue at all. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 04:31, 11 March 2018 (UTC)
 
 
 
:You can use the undocumented {{ic|--ask}} flag (see pacman git log) or better, {{ic|pacinstall --remove}} from {{Pkg|pacutils}} which has the ability to install and remove packages concurrently. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:20, 12 March 2018 (UTC)
 
 
 
:: Thanks! Is there a similar way to avoid extra question in 'makepkg --syncdeps --rmdeps'?
 
:: UPD: i've also updated pikaur to avoid using --nodeps and --noconfirm. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 03:33, 13 March 2018 (UTC)
 
 
 
::: I don't know, you can try passing {{ic|--ask}} to makepkg I guess. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:58, 18 March 2018 (UTC)
 
 
 
:::: That was the first i've tried, but makepkg was complaining what it's unknown argument. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 05:34, 20 March 2018 (UTC)
 
 
 
::::: Yep, it looks like the arguments are hardcoded: [https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in#n270] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:44, 20 March 2018 (UTC)
 
 
 
=== <s>Separation of pacman commands</s> ===
 
 
 
I want some clarifications on the difference between:
 
1) {{ic|pacman -Su}} and {{ic|pacman -S $(pacman -Quq)}}
 
2) {{ic|pacman -Syu}} and {{ic|pacman -Sy ; pacman -Su}}
 
[[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 03:38, 20 March 2018 (UTC)
 
 
 
: Some helpers like {{AUR|yay}} separate a -Syu not only into -Sy + -Su, but into -Sy and then appending the updated packages to pacman -S. As linked above, this makes it very hard to distinguish if a partial upgrade was performed or not.
 
: A separation to -Sy + -Su is less bad, or at least not much worse than a user interrupting an -Syu after the databases were synced. It's still not standard behavior though. I guess you'd do it to format output? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 03:53, 20 March 2018 (UTC)
 
 
 
:: I think we need to reconsider criteria for that section. I think the best way will be to split the helpers into 3 categories:
 
::  1) precise pacman wrapping
 
::  2) some minor things like example above, but without potential db breakage
 
::  3) like --nodeps or so
 
::  [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 05:28, 20 March 2018 (UTC)
 
 
 
:: In pikaur i do that separation not only to format output but also in order to compute the conflicts (to ask about them in advance, however conflicts themselves are resolved via ask, not manually). Also to be able to manually edit list of packages. I hope i didn't forgot anything else.  [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 05:32, 20 March 2018 (UTC)
 
 
 
::: AUR helpers that require full pacman reimplementations with libalpm and/or strange command lines to achieve the same thing as helpers that do none of these don't need the same recognition on the table. 3) is basically a Yellow entry, 1) green.
 
::: If you want 2) to be green you'd need all kinds of exceptions which I doubt is very helpful (cf. Spyhawk's comment on "quick reference"). An alternative would be to keep onorthodox things beyond an optional flag. Like aurman has the --do-everything flag, which if it were default, would warrant it a red table entry. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 05:55, 20 March 2018 (UTC)
 
 
 
:::: I was thinking 1) green; 2) yellow; 3) red.  [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 06:00, 20 March 2018 (UTC)
 
 
 
:::::Well, I'm not sure I'd give a helper a red entry solely for it using e.g. {{ic|pacman -Ud}} someplace. On the other hand, for pikaur's case another report sprang up which I assume is again due to its pacman reimplementation: [https://github.com/actionless/pikaur/issues/80]
 
:::::My issue is to give designs based on reimplementing pacman anything more than red, for the same reason as what's in the warning at the top of the article. The authors can claim that their implementation is correct and has no breakage when using it over {{man|8|pacman}}, but in the end it's fully unsupported by anyone on the arch or pacman team.
 
:::::Giving users an ability to easily check whether they use some custom/unsupported implementation was the main motivation behind this new column, rather than the overly broad warning "don't use pacman wrappers at all". This doesn't mean you can't use libalpm or other manual implementations at all - most of the entries on the table do in some way - it's about the scope of things and whether using {{ic|$HELPER <some operation usually done with pacman>}} will actually have the same effect as {{ic|pacman <some operation usually done with pacman>}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:10, 20 March 2018 (UTC)
 
 
 
:::::: I am not saying what you need to lower down an alarm level for pikaur. I am saying what you need to increase the alarm level (mb with additional marks) for those helpers which are using things like --nodeps or other potentially damageable for the package db consistency. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 06:17, 20 March 2018 (UTC)
 
 
 
:::::::Oh, right. Well that sounds fair to me. It's not like we have these distinctions in the "inactive" section or the "secure" column either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:20, 20 March 2018 (UTC)
 
 
 
::::::::Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&type=revision&diff=514218&oldid=514198]. I guess if we have a helper that really only does minor things like pacman -Sy && <do some parsing> && pacman -Su that a yellow entry might fit. Or as said, do -Syu by default and add a --fancyparse flag or such. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:26, 20 March 2018 (UTC)
 
 
 
:::::::::Note that in most cases a link should suffice, e.g. a github post where it is explained why pacman -Syu is done but split to -Sy and -Su. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:39, 20 March 2018 (UTC)
 
 
 
::Let me try to explain, why splitting {{ic|-Syu}} to {{ic|-Sy}} + {{ic|-Su}} is the only way to do things right and not harmful at all.
 
::1. {{ic|-y}} option is a special option which can be used not only for installing packages: {{ic|-Syi}}, {{ic|-Sys}}, {{ic|-Syg}}, etc. Refresh always happens before any of these operations start. They are not atomic, as well as {{ic|-Sy package}} or {{ic|-Syu}}. There are also delays between refreshing repos, there is delay for some calculations which happen after refresh. Splitting {{ic|-Syu}} to {{ic|-Sy}} and {{ic|-Su}} only makes this delay longer and nothing more.
 
::2. {{ic|-Su package}} operation is atomic. Reimplementing this operation as {{ic|-Su}} + {{ic|-S package}} is wrong. At least, user would be asked twice.
 
::3. Let's look at this specific case: {{ic|-Syu package}}, when package {{ic|package}} was moved from AUR to Arch repos. Before refresh, we can't know our package present in repos, so we can't check AUR db before {{ic|-y}}. On the other hand, we shouldn't split {{ic|-Su package}} to {{ic|-Su}} + {{ic|-S package}} (see above), which means we should know whether package in repos or not, so we could call {{ic|pacman -Su package}} or just {{ic|pacman -Su}} depending on package presence. This means that the only right place to check AUR db is after {{ic|-Sy}} but before {{ic|-Su package}}. [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 10:56, 20 March 2018 (UTC)
 
 
 
::: It's not "the only right way", it's "the way of trying to do too much". @Polygamma maybe you could expand on this since aurman doesn't separate -Syu, does it? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 20 March 2018 (UTC)
 
 
 
:::If a package is moved from AUR to the Arch repos, {{ic|pacman -Syu package}} would do the right thing so you wouldn't need to check the AUR at all, since even if the package was still in AUR, the official package should take precedence. If the package is moved from the Arch repos to the AUR, {{ic|pacman -Syu package}} would fail and I think it's important to show that to the user to decide if he still wants the package. In other cases, you can check the AUR whenever you want. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:55, 20 March 2018 (UTC)
 
 
 
::::In AUR → Arch repos case, AUR helper should decide which call to perform: {{ic|pacman -Syu}} or {{ic|pacman -Syu package}}, depending on package presence so pacman doesn't fail. But how AUR helper supposed to know that before refresh? -- [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 12:18, 20 March 2018 (UTC)
 
 
 
:::::You can simply use the old database(s) to cover the 99.9% cases when the packages are not moved and deal with the rest when something fails - seems better than risking partial upgrades in all cases. Or if you insist on always having an up-to-date databases for the decision, use a separate sync database like the ''checkupdates'' script. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:52, 20 March 2018 (UTC)
 
 
 
::::::What partual upgrades risk? If AUR helper runs {{ic|-Su}} after {{ic|-Sy}}, pacman will do full system upgrade. AFAIU partial upgrade is installing packages after {{ic|-Sy}} without {{ic|-Su}}, but that's not the case. Could you explain the difference between {{ic|-Syu}} and {{ic|-Sy}} + {{ic|-Su}} then? -- [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 23:59, 20 March 2018 (UTC)
 
 
 
:::::::[[Partial upgrades]] are exactly about the delays between {{ic|-Sy}} and {{ic|-Su}}. If they follow right after each other, in which case you wouldn't need to split them, then it's fine. If you do things which could fail by themselves or be aborted by the user, like querying the AUR, downloading sources and presenting PKGBUILDs to the user (this is what "batch interaction" means, right?), then you have a problem. I hate to break it to you, but if you query the AUR before {{ic|-Su}} and cache it until {{ic|-Su}} is complete, you should query it again because {{ic|-Su}} might take hours on a slow network, so the first query is useless. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:25, 21 March 2018 (UTC)
 
 
 
::::::::So, partial upgrade happens if operation was aborted for some reason, right? But pacman can fail itself: {{ic|pacman -Syu qweasd}} (package {{ic|qweasd}} is not exist, so pacman will also fail to upgrade). User can abort pacman during refresh (repos will be synced partially) or during packages download. The only thing I do is querying AUR database and asking about ignored packages; git clones and "view file" asks are deferred. I think I can defer the rest questions (about ignored packages/etc) as well. In this case, will {{ic|-Sy}} + {{ic|AUR query without fails and asks}} + {{ic|-Su}} be still considered as partial upgrade? -- [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 13:12, 21 March 2018 (UTC)
 
 
 
:::::::::In any event, such behavior will warrant a yellow label at best, as suggested by @Actionless. If you want something green, consider a more clever mechanism like the JSON interface or make it optional behind a flag. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:28, 22 March 2018 (UTC)
 
::::::::::Note: to me it seemed that pakku also has a whole lot of pacman reimplementation going on through some home-made libalpm interface but I could be mistaken. If not that definitely warrants a red label. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:25, 22 March 2018 (UTC)
 
 
 
::::::::::Pakku uses libalpm for queries used in calculations. It's much faster to call necessary functions than parsing pacman/expac/etc's output, which ultimately leads to the same result. Pakku doesn't alter database. -- [[User:Kitsunyan|Kitsunyan]] ([[User talk:Kitsunyan|talk]]) 21:08, 22 March 2018 (UTC)
 
 
 
:::::::::::[https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=514652&oldid=514651] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:07, 24 March 2018 (UTC)
 
 
 
::::::About the "we can't know our package present in repos" part - the official repos, much like the AUR, have a [[Official_repositories_web_interface|JSON interface]] so you could just query that to get the latest information, independent of mirrors or synced dbs. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 01:47, 21 March 2018 (UTC)
 
 
 
=== <s>Separation of pacman commands - Summary</s> ===
 
 
 
Since we all seem to be on the same page that {{ic|pacman -Sy && pacman -S ''packages''}} is bad, what remains is how to classify {{ic|pacman -Sy && ''do_stuff'' && pacman -Su}}. A few more comments were done here: [https://github.com/actionless/pikaur/issues/81] Options:
 
 
 
# Leave a green entry for helpers that exactly use {{ic|pacman -Syu}}. Anything else gets a yellow or (on further issues) red entry. When checking if a target package is in the repo, use one of the following:
 
#*The official repositories [[Official_repositories_web_interface|JSON interface]]
 
#*A temporary copy of the database using {{ic|fakeroot}}
 
#*Assume the copy of the pacman sync dbs is up-to-date
 
#**Optionally add a commandline flag that allows a prior {{ic|pacman -Sy}}
 
# Leave a green entry for helpers that exactly use {{ic|pacman -Syu}} OR {{ic|pacman -Sy && do_stuff && pacman -Su}}. The description of the "pacman wrap" feature is updated accordingly.
 
# As 2. but with some special distinction such as '''Yes*'''.
 
 
 
In favor of 1. speaks that helpers who put in special effort to only use canonical pacman commands are rewarded accordingly.
 
 
 
In favor of 2. or 3. is that pacman itself does -Sy && -Su anyway. [https://github.com/actionless/pikaur/issues/81#issuecomment-375854751] However, as pointed out above, helpers may add additional steps between the -Su and -Sy steps that have additional chance of failure, increasing the chance of a partial upgrade. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:54, 24 March 2018 (UTC)
 
 
 
:Following up on the above discussion: assuming you minimize the steps between -Sy and -Su that may add additional failure, how do you classify this in the table without losing the "quick reference" aspect or adding verbose exceptions to the column description? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 24 March 2018 (UTC)
 
::This is where I think the strength of using a yellow label lies. It tells you that it's "okay" but that there may be some risk involved from a custom command-line. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:13, 24 March 2018 (UTC)
 
:::As I've mentioned before, Pacman does {{ic|-Sy && -Su}} internally so it is my opinion that there is no difference between {{ic|-Sy && -Su && aur stuff}} and {{ic|-Sy && aur stuff && -Su}}. If you want to label this as yellow then Pacman itself should deserve yellow if it were to be in the table. As long as an AUR helper makes it impossible to do a partial upgrade (I am not counting a database update without a package upgrade a partial update in this context because Pacman can do that with -Syu anyway) then it deserves green. For example {{ic|-Sy && aur querying && -Su && aur install}} which I assume is how most AUR helpers that split it do things. If the querying is to fail then no packages should be upgraded and it is then the users responsibility to try again or preform an upgrade directly through Pacman. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 23:46, 26 March 2018 (UTC)
 
 
 
::::If you really think that there is no difference between {{ic|-Sy && -Su && aur stuff}} and {{ic|-Sy && aur stuff && -Su}}, then your AUR helper should do the former and we don't need this discussion at all.
 
::::To stay with the point, note that although pacman itself separates {{ic|-Sy}} and {{ic|-Su}}, there is ''no thing that could fail'' between the two operations. Hence, if an AUR helper aborts due to the failed operation between {{ic|-Sy}} and {{ic|-Su}}, this is inherently a different situation from pacman and thus in a way an abuse of pacman's semantics, which deserves a yellow in the table. To get a green, you'd have to do {{ic|-Su}} even if the {{ic|aur stuff}} before it failed, but if you could do that you might as well do {{ic|-Syu}} at the very beginning...
 
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:39, 27 March 2018 (UTC)
 
 
 
:::::The difference is that an AUR helper can know about updates and present them along side the AUR updates. Just like how Pacman needs to do {{ic|-Sy}} before {{ic|-Su}} to know what to update.
 
:::::You say "no thing that could fail between the two operations." But that is completely wrong. The user could hit N instead of Y, run out of space, Have broken mirrors, conflicting files, be missing keys, ect...
 
:::::It's not like AUR helpers hide what they are doing. Database updates are clear. Failures are clear. They never run {{ic|-Sy}} unless y was actually specified by the user.
 
:::::[[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:14, 27 March 2018 (UTC)
 
 
 
::::::The things you're naming that could fail happen ''after'' {{ic|-Su}} has started, not ''between'' {{ic|-Sy}} and {{ic|-Su}}. The point is that pacman does not fail due to AUR stuff and AUR helpers should not insert failing stuff between {{ic|-Sy}} and {{ic|-Su}}, otherwise they ''are hiding'' stuff. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 27 March 2018 (UTC)
 
 
 
:::::::What's there difference between failing during {{ic|-Su}} and between them? They both have the same outcome. AUR helpers add support for the AUR. As well as supporting installs they should also support erroring when something is not right, just like how Pacman will error if something is wrong in the official repos side.
 
:::::::If the user does not want to deal with the possibility of failure they should not be doing {{ic|helper -Syu}}. It is the helper's job to try ensure the whole operate succeeds. If the user does not care if the whole operation succeeds they should run the Pacman update and AUR update separately. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:50, 27 March 2018 (UTC)
 
 
 
::::::::The outcome is not the same - a failure due to AUR does not clearly indicate that plain {{ic|-Su}} is needed to complete the operation. So the {{ic|-Syu}} operation specified by the user should not fail for a different reason than in pacman. If {{ic|-Syu}} is supposed to mean something different in an AUR helper than in pacman, the flags should be explicitly different to avoid any confusion - otherwise it deserves a yellow (or red) cell in the table. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:15, 27 March 2018 (UTC)
 
 
 
:::::::::{{ic|pacman -Syu}} and {{ic|helper -Syu}} are meant to be different things, the flags do not need to be explicitly different. If you want it to behave ''exactly'' like Pacman then use Pacman. AUR helpers typically take Pacman's syntax style and extend it. They are not the same program, they behave differently, I expect every one to understand that.
 
:::::::::{{ic|-Syu}} means upgrade all packages. Pacman will fail if it can not upgrade all packages. AUR helpers should do the same. This brings the behaviour closer to how Pacman does things.
 
:::::::::The question I'm left with now is do I change my helper so that there is no split just to get that green cell. Or do I keep the yellow, sacrificing what others will think for what I believe to be better behaviour.
 
:::::::::That's about all my thoughts on the issue, unfortunately I couldn't change your mind.
 
:::::::::[[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 22:47, 27 March 2018 (UTC)
 
 
 
::::::::::First let me point out that I don't get that obsession over getting a green color over a yellow one. If you mean because it's low in the table so that potential users might oversee it, that's merely because of alphabetical reasons ('''y'''ay). Note that yay having a red entry is due to more factors than an {{ic|-Syu}} separation: it uses unsupported commands like {{ic|pacman -Rdd}} and from what I saw, it uses alpm directly to a much greater extent than other AUR helpers.
 
::::::::::Otherwise I don't get the point. {{ic|-Syu}} is more than a flag, it's a procedure that's engrained into the workflow of most arch users - if a pacman ''wrapper'' suddenly decides to (sometimes drastically) change while keeping the same terminology, that's not something to be encouraged. See e.g. the forum post I linked right at top where differences between pacman -Syu and yay -Syu caused vast confusion in both the user seeking help and those trying to offer it.
 
::::::::::My opinion remains that making such behavior optional (like aurman does) would be a good compromise. Then anyone who sees {{ic|yay -Syu}} can assume it does the equivalent of {{ic|pacman -Syu}} and anyone who sees {{ic|yay -Syu --ermagherd}} cann assume it is not.
 
::::::::::In any case, I much appreciate {{ic|pakku}} having a wiki entry where it exactly describes how it wraps pacman. Then regardless of what color some entry in a table has, the user can make an informed decision. If you disagree with the optional flag that's what I'd suggest to do. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:13, 27 March 2018 (UTC)
 
 
 
:::::::::::My 'obsession' is just me disagreeing and wanting to share my opinion when I believe others are wrong. It's not about getting green but simply debate.
 
:::::::::::I didn't mention red because I know Yay effectively did {{ic|pacman -S of pacman -Qu}} which deserves red. I will point out I did not implement it this way. I already fixed that issue and changed it to run {{ic|pacman -Su}} but that's only in the -git and I'm not changing the table entry until the next release.
 
:::::::::::Also Yay does not use -Rdd and like other helpers it uses alpm for querying only so I don't see how it's relevant to point out.
 
:::::::::::When it comes to "{{ic|-Syu}} is more than a flag, it's a procedure" I agree, and I think splinting it to {{ic|-Sy && repo cheking && aur checking && repo upgrade && aur upgrade}} Is closer to the process that Pacman follows than {{ic|-Sy && repo checking && repo upgrade && aur checking && aur upgrade}}.
 
:::::::::::[[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 23:48, 27 March 2018 (UTC)
 
 
 
::::::::::::Back when I looked at the code it explicitely ran {{ic|pacman -Rdd}} when dealing with conflicts. I pointed this out and was ignored, so unless you point me to a commit where this was removed it's safe to assume it still does. That leaves comments like [https://github.com/Jguer/yay/issues/146#issuecomment-365358542] by the upstream author; I really don't understand the modern helper trend of reimplementing pacman rather than simply use it. Otherwise we're just going in circles. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:02, 28 March 2018 (UTC)
 

Latest revision as of 13:29, 24 October 2019

Legend editions

Special:Diff/573543/573551: Good revert, I did these late into sleepless night and did not notice this were huge and not that thought through changes :/

  • Merge note definitions for partial and optional as part of legends list? This was a mistake, note there exactly makes sense according to style rules.
  • Add known used unsafe flags to legend, add that asterisk means optional, as it may be unclear?
  • Move legend concerning pacman wrappers only inside its section? Alternatively mention these apply only to pacman wrappers, example text:
Unsafe flags
Potentially harmful pacman flags that could be used by #pacman wrappers.
Note: Asterisk means these pacman flags are optionally enabled.
Batch interaction
Ability of #pacman wrappers to prompt before the build process and package transactions, in particular:
  1. Combined summary of repository and AUR package upgrades;
  2. Resolution of package conflicts and choice of providers.

-- Svito (talk) 07:33, 22 May 2019 (UTC)

Batch interaction isn't specific to pacman wrappers, at least not 2. The legend denotes it as a column though, which it isn't. At the same time, I'm not sure if replacing "columns" with "columns and values" is a good idea.
If we document all the unsafe flags, I would argue it's out of scope in this article and should be expanded in System_maintenance#Avoid_certain_pacman_commands instead. (Side-note: what if a regular AUR helper uses an unsafe command to e.g. install dependencies? None of the current entries do, but it's a possible scenario.) -- Alad (talk) 13:26, 25 May 2019 (UTC)
How about expanding the note:
Note:
  • Optional means that a feature is available, but only through a command-line argument or configuration option. Partial means that a feature is not fully implemented, or that it partially deviates from the given criteria.
  • Batch interaction indicates the ability to prompt before the build process and package transactions. In particular:
1. Combined summary of repository and AUR package upgrades;
2. Resolution of package conflicts and choice of providers.
I've looked at System_maintenance#Avoid_certain_pacman_commands again and it contains all needed detail already, apart from the --ask option which is niche (and linked from in the table where appropriate). -- Alad (talk) 22:02, 25 July 2019 (UTC)

Add yup to Pacman wrappers

Links: github yupAUR

Right now yup ticks every box in the 'Pacman Wrappers' table except for 'Split packages'. It has code completion working mostly in zsh and will soon support bash and fish too.

Pros:

It fetches pgp keys for you. It shows the PKGBUILD before installing by default for security reasons. It shows far more relevant search results that other AUR helpers on the market.

Ericm (talk) 14:52, 21 July 2019 (UTC)

It's another yaourt clone - pretty sure we have enough of those in the table already. -- Alad (talk) 20:11, 21 July 2019 (UTC)
Even though it's got tonnes of features that yaourt doesn't have? Ericm (talk) 20:40, 21 July 2019 (UTC)
I would argue the splitting into "packages" is the main distinguish feature - things like an ncurses interface are superficial in my book.
Generally speaking, most AUR helpers have turned out to be either vaporware or small variations on existing work. Some recent examples: aursAUR, baphAUR, gutaurAUR, ramAUR, raur-gitAUR, simpleaur-gitAUR, vamAUR. So let's wait a bit how this projects evolves before adding it to the wiki. -- Alad (talk) 21:56, 25 July 2019 (UTC)
Looks like it's still around after 3 months, so it could be added to the article. Would be nice if someone else than upstream tests the column entries, though. Also don't expect to have "far more relevant search" added, because that could basically mean anything. -- Alad (talk) 11:37, 10 September 2019 (UTC)

Octopi no longer performs partial upgrades

According to this GitHub comment as well as this commit, Octopi no longer does partial upgrades as this page says it does.

CodingKoopa (talk) 18:14, 25 July 2019 (UTC)

Thanks: Special:Diff/578024 -- Alad (talk) 19:46, 25 July 2019 (UTC)

Update information on rua?

Please update information on RUA helper. "Diff view" and "Split packages" were implemented, as per the linked issues. Also, please add "shellcheck" and "local patch application" to the list of features that the helper has. The second is most probably not unique, the first one is unique I think. Vasya (talk) 17:28, 23 August 2019 (UTC)

To be specific on "split packages" support. I've made another manual test on the latest released version of the helper. 1. Tried to install both clion and clion-jre at the same time. RUA only builds it once (`rua install clion clion-jre`). 2. Requested to install `libc++`, it understands that it only needs to be built once but both packages are installed. 3. When trying to install python2-pyalsaaudio, rua correctly builds pkgbase python-pyalsaaudio, and then installs python2-pyalsaaudio. Vasya (talk) 11:31, 26 August 2019 (UTC)
First request satisfied with Special:Diff/581029. Let's wait for opinion on other features. -- Svito (talk) 11:57, 26 August 2019 (UTC)
Thanks for actually testing this. Regarding the suggested features: running shellcheck before sourcing the PKGBUILD is trivial. I'm not sure what's meant by "local patch application" - does rua support git rebase with local commits, or does it just not undo local changes in the worktree e.g. through git --autostash? -- Alad (talk) 11:34, 10 September 2019 (UTC)
Regarding shellcheck. It's not THAT trivial. For example, this is the output of `rua shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/7bcbc5fc6ebf731abc8399988dfb4fef. Compare it to the output of raw `shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/edb08becb9ed7dd558b4c8655b57adec. That being said, `rua shellcheck` is not ideal as well. For example, it will always approach $pkgname as an array, and warn on all usages of the variable that treat it as non-array.
Regarding patch application. It keeps your locally reviewed state in a separate branch. Whenever you're ready to merge upstream, it basically does `git merge upstream/master`. You can drop to shell and do a manual rebase as well if you want, though only merging is streamlined as a built-in action. It is also safe for e.g. aborting the installation, because, unless you manually merge upstream changes yourself, changes won't ever leak into your "accepted" state (local branch). Building without merging upstream/master is forbidden as a foolproof. Vasya (talk) 16:12, 12 September 2019 (UTC)

pacaur is also discontinued

According to the project github and discussion on archlinux forum pacaur is discontinued C13251 (talk) 13:14, 24 October 2019 (UTC)

I think you are confusing the discontinued repo: https://github.com/rmarquis/pacaur with the fork: https://github.com/rmarquis/pacaur The fork seems pretty much alive. Vasya (talk) 13:29, 24 October 2019 (UTC)