Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
(answer why pacaur is still supported)
 
(99 intermediate revisions by 19 users not shown)
Line 1: Line 1:
== "Reference" implementation ==
+
== Legend editions ==
  
This is an alternative to [[Special:Diff/525492#Reliable Updater|#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.
+
[[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 :/
  
I propose a minimal reference implementation with the following points:
+
* <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:
  
* 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.
+
:;Unsafe flags: Potentially harmful pacman flags that could be used by [[#pacman wrappers]].
* Minimal language constructs in e.g. a scripting language like {{Pkg|dash}}.
+
::* {{ic|--ask}} – [https://git.archlinux.org/pacman.git/commit/src/pacman?id=90e3e02 Undocumented option] to be used for testing only;
* Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.
+
::* {{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.
  
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)
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 07:33, 22 May 2019 (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)
+
: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)
  
::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.
+
::How about expanding the note:
::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)
+
{{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)
  
::: 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.
+
== Add yup to Pacman wrappers ==
::: 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)
 
  
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
+
Links:
 +
[https://github.com/ericm/yup github] {{AUR|yup}}
  
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
+
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.
  
The new criteria would be as follows:
+
Pros:
* PKGBUILD, no other files -> Partial
 
* Other subset of files that includes the PKGBUILD -> Partial
 
* No PKGBUILD -> No
 
* All files in the git repo or tar archive -> Yes
 
  
Similar to the ''Diff view'' column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:32, 4 July 2018 (UTC)
+
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.
  
: good idea, you also mentioned this for aurman a few months ago, see: https://github.com/polygamma/aurman/issues/25#issuecomment-371971155 really a good idea to implement it in a way, so that changes of all known files are being shown [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:07, 4 July 2018 (UTC)
+
[[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 14:52, 21 July 2019 (UTC)
  
: "All files in the git repo or tar archive -> Yes" What exactly do you mean by all files? Build files often contain non text files such as images. Git diff is smart enough to hide these but then you could consider that partial because not all files are covered.
+
: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)
: In my opinion all a helper has to do to be secure it pause and allow the user to read the build files. The helper does not even need to offer to open them for you that's the user's responsibility. Anything more than that is nice to have but not strictly needed. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:25, 4 July 2018 (UTC)
 
  
:: If this qualifies as "nice to have", there has to be an explicit warning that a green entry in the "Secure" column does not cover other files, files which may cause more harm than the PKGBUILD itself (such as {{ic|.install}} files or exectuables called from the PKGBUILD). In either case it's misleading, since you either give the impression that viewing PKGBUILDs alone is sufficient (with the current criteria), or include a warning that diminguishes the value of the criteria in the first place.
+
:: 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)
:: Latter is similar to "Native pacman", in that you have a warning at the article top warning against any sort of pacman wrapping, and criteria in the table that ignore this warning, or even reward behavior which goes against it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:07, 8 July 2018 (UTC)
 
  
::: That's a fair point, what about changing the name to "show files before sourcing" or something? Seems more accurate. Then it would make sense that not showing .install files to be partial. The only problem I see that it's not as hard hitting as "secure". [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:11, 8 July 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)
  
:::: It cuts both ways: it's an effective deterrent against broken helpers, but it also gives the impression that using a "Secure" helper makes usage of the AUR safe, which it definitely doesn't. I'm not sure on what different name to use, though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:25, 14 July 2018 (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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:37, 10 September 2019 (UTC)
  
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (UTC)
+
== <s>Octopi no longer performs partial upgrades</s> ==
  
:::::: The column name was updated to "File review". Are there remaining helpers that only display the PKGBUILD? ({{AUR|trizen}} springs to mind) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:30, 23 August 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.
  
== New test cases for dependency resolution ==
+
[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:14, 25 July 2019 (UTC)
  
ros-foo-desktop-meta have always been difficult to build, even more so with KDE4 libs moved to AUR (see arch-dev-public). Besides the sheer number of dependencies, they otherwise have little interesting properties either.
+
:Thanks: [[Special:Diff/578024]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:46, 25 July 2019 (UTC)
  
I propose to instead use various cross-compilation packages as test cases, e.g. {{AUR|mingw-w64-zlib}} and {{AUR|powerpc-linux-gnu-gcc}}. These appear very efficient at exposing problems with complex dependency algorithms (see for example [https://github.com/Jguer/yay/issues/695] or ''aurman'''s issues with {{AUR|nsis}}) and don't take 2 years to build either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:34, 14 September 2018 (UTC)
+
== Update information on rua? ==
  
:We could also add some simpler cases, like {{AUR|fortune-mod-all-en}}, and add details similar to the ''Split packages'' description. That way, all existing entries with "Yes" in ''Reliable solver'' would at minimum have "Partial". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:01, 14 September 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)
  
:I believe the mingw stuff has a bunch of circular dependencies and a bootstrapping process. Do you think AUR helper's should be expected to handle this? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 15:25, 14 September 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)
  
:: No, I don't think so. There will always be cases that can only be dealt reasonably manually, simply because the involved complexity in implementation isn't worth it. See also related sicussion [[Talk:AUR_helpers#.22Reference.22_implementation]] above, where a set of fixed reference packages would be better than live packages. No idea how to dealt with than without a local AUR instance though. -[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 10:42, 15 September 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)
  
::: The mingw packages haven't had cycles in (global) depends for a while. As such, {{ic|makepkg -r}} works fine for these packages without manual intervention or "bootstrapping". If helpers fail, it may be because of handling split depends contrary to PKGBUILD(5), or other flaws in their dependency algorithms. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 18 September 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)
  
== <s>remove Batch interaction 2</s> ==
+
:::: 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)
  
:Some previous discussion: [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&oldid=545415#proper_batch_interaction_2_and_3]
+
== pacaur is also discontinued ==
On IRC there was some confusion on what "Summary of package upgrades" is supposed to mean. Literally, it means that any (AUR) upgrades or installations a helper will perform are printed to screen, similar to pacman's VerbosePkgLists. This is simple to implement - by definition a AUR helper must know about package names and their versions - and does not warrant a separate mention.
 
  
Historically, it's about pacman wrappers running -Sy so they can 1. save a single keypress 2. color the output. Former is a questionable argument when all pacman wrappers have a single prompt per package (so potentially hundreds of keypresses), and latter is already available from pacman itself. (with the Color option) As such, I propose to remove batch interaction 2 from the criteria. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:52, 7 November 2018 (UTC)
+
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)
  
:: If I might jump in, I don't think "one less key press" is a valid argument, nor does the color which is orthogonal to the feature. Batch interaction is not strictly about reducing the number of keys one has to enter, but it is about reducing the time required by... well, batching every step at the beginning. Batch 2 is about grouping repo *and* AUR packages summaries and initial validation together, rather than doing the repo packages update, then displaying the AUR summary before the AUR packages update. I'd suggest adjusting the current loose definition here. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:00, 7 November 2018 (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. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 13:29, 24 October 2019 (UTC)
 
 
::You what? The "color" that pacman does, is bold text for some things, making "warning" in yellow and "error" in red, and, for the -Ss or -Qs operations, coloring the repository name in purple, the version in green, and the "[installed]" in light blue.
 
::But the output of pacman -S(u) contains practically no color, and *significantly* less color than the average AUR helper. Yaourt could be considered the trendsetter in that regard, and it colors each repository differently, as well as making old versions show in green and new versions in red, on top of pacman's existing complete lack of color for that area of the UI.
 
::Furthermore, the actual main thing which, say, yaourt provides, is 1) grouping AUR updates in the same VerbosePkgLists style, 2) differentiating between packages which are being upgraded, vs. being pkgrel-bumped, vs. being newly installed, 3) listing which package update now requires a new package to be installed. These are fairly significant deviations from pacman's UI, and IMHO more noticeable than the color. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:50, 9 November 2018 (UTC)
 
 
 
:::So as I understand either argument, neither disagrees with "2" only being relevant to pacman wrappers that run {{ic|pacman -Sy}}. As such, I'm not sure why it should be a general criterium, rather than a specificity. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:09, 28 November 2018 (UTC)
 
 
 
:::: It's indeed only specific to pacman wrapper, but still an important part of batch interaction (1 action vs 2 actions separated by some amount of time). I'm not sure why it shouldn't be mentioned for the sole reason it only applies to wrappers. I'd suggest to either mention it (with a correct definition), or move all batch interactions as specificity - which I'd personally be fine with. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 15:25, 28 November 2018 (UTC)
 
 
 
::::IMHO whether it uses {{ic|pacman -Sy}} is an implementation detail. More importantly, I think it qualifies as a ''dependency'' of batch interaction, but is not, itself, batch interaction.
 
::::I'd also like to note that Batch interaction #1 is, unless I totally miss my guess, a direct copy of the "file review" column.
 
::::Neither 2 nor 3 are something which can be universally defined as necessary for robustly doing anything, unlike most columns, and unlike the implementation language aren't fundamentally relevant to all programs by default, I think it is fair to demote them both to specificity as "you may prefer to do it this way instead of that way". -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:45, 28 November 2018 (UTC)
 
 
 
:::::The term "batch interaction" used to be included as a specificity, without explicit definition it was however not clear what this meant. I'm fine to go back to this approach, as long as we have some meaningful definition/term for the separate "batch interaction" aspects.
 
:::::Regarding #1, it's not a direct copy since "file review" can be done on-demand, i.e. whenever a new PKGBUILD is about to be sourced (yaourt), and not ahead of time before ''any'' build process begins (pacaur & co). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:00, 30 November 2018 (UTC)
 
 
 
::::::In a previous discussion we mentioned to have 4-5 entries per Specificity cell. In anticipation of the above additions, I've removed the (imo superficial) "sort by votes/popularity" criterion. Please review: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=557839&oldid=557838] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:09, 30 November 2018 (UTC)
 
 
 
::::::I guess it is sort of obvious that batch interaction means any features that it has, including file review, will be done via batch operations rather than on-demand. So it is still redundant IMO. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 23:45, 1 December 2018 (UTC)
 
 
 
:::::: Unlike a few years ago, batch interaction 1 is now a standard feature in all maintained helpers. It doesn't make much sense to keep an extra column for the sole purpose of mentioning it. I'd move everything to specificity imho. If you need to keep definitions, I'd suggest something like: "Ability to prompt before the build process and package transactions", in particular: 1/ "Inspection of package files or their differences" (same as current), 2/ "Combined summary of repository and AUR package upgrades", 3/ "Resolution of package conflicts and choice of providers." (I'm not sure what the current "installation" refers to here) -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 00:30, 2 December 2018 (UTC)
 
 
 
::::::: What do you think of "resolve package conflicts" and "combined upgrade" (for 2/ resp. 3/) as specifity? (see my draft). Your descriptions sound good though, and can be referred to from the Specificity column if required. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:46, 2 December 2018 (UTC)
 
 
 
:::::::: I dislike how my previous suggestions are overly long, but I'm afraid "resolve package conflicts" and "combined upgrade" are too generic and not descriptive enough for someone that doesn't know what batch interaction is. Ideally, these should emphasis that the actions are done prior to build and transactions. Maybe "early conflicts resolution" and "combined upgrade summary"? Rest of the draft LGTM. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 15:37, 2 December 2018 (UTC)
 
 
 
::::::::: I prefer the longer descriptions. We can refer to them in the Specificity column, e.g. through ''Batch interaction 2/3''. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:54, 8 December 2018 (UTC)
 
 
 
::::::::: I just added "batch interaction" for now if the helper at least supports batch 3/. Most of the other stuff in the Specificity column was not interesting (functionality such as AUR comments and ABS support is easily replicated with external tools like {{AUR|aur-talk-git}} or {{Pkg|asp}}) so I've removed it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:10, 8 December 2018 (UTC)
 
 
 
== <s>Checkmarks instead of colors</s> ==
 
 
 
I propose to use ✅ (U+2705) and ❎ (U+274E) instead of [[Template:Yes]] and [[Template:No]]. While uncommon in the wiki, the checkmarks are more subtle than fully colored cells, and might lead to a more thoughtful response when choosing helpers (compare the common "pick the all green row" responses we have now).
 
 
 
Example: [http://i.imgur.com/UzMFr7u.png] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 30 November 2018 (UTC)
 
 
 
:That check mark has different appearance depending on [https://emojipedia.org/white-heavy-check-mark/ Emoji font]. There is [[Template:Ya]] and [[Template:Na]] that use colored text-presentation symbols, but one would probably figure out that "pick the all green row" is similar to "pick the row with all checkmarks", especially since both ✅ (U+2705) and [[Template:Ya]] have green color. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 18:28, 30 November 2018 (UTC)
 
 
 
:You could also use plain text "Yes" and "No" instead of the templates if you want to skip the colors. But due to the sorting criteria users probably tend to choose from the top... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:29, 30 November 2018 (UTC)
 
 
 
::Draft [[User:Alad/AUR_helpers]]:
 
::* Removes sorting criteria, sort alphabetically instead;
 
::* Remove batch interaction 2 and 3 as column entries, add "resolve package conflicts" and "combined upgrade" to specificity instead;
 
::* Replace [[Template:Yes]] with [[Template:Ya]] and [[Template:No]] with [[Template:Na]];
 
::: As an alternative to the checkmarks (better suited for screenreaders), see: [http://i.imgur.com/hwK9tl9.png]
 
::* Remove some redundant specificity entries to keep a maximum of 4 entries;
 
::* Remove Batch interaction 1;
 
::For the last point, while it's a separate aspect of "file review", 80% of the helpers support it by now. I'd rather have the additional space from having one column less. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:06, 1 December 2018 (UTC)
 
 
 
:::In line with the added neutrality from removing the sorting criteria, I'd also suggest to move "stalled" entries back (as non-grey entries) to the table. It should already be clear that any helper with crosses across the board is "stalled". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:12, 1 December 2018 (UTC)
 
 
 
::::Implemented changes in the draft, apart from the checkmarks due to [[accessibility]] concerns. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:15, 8 December 2018 (UTC)
 
 
 
== <s>Responsive tables</s> ==
 
:Moved from [[#Checkmarks instead of colors]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:14, 8 December 2018 (UTC)
 
 
 
The only thing that still bothers me is that even with the limit on the amount of specificities, there's so many columns in the table (especially for pacman wrappers), that on small screens every word is split by a newline. [[User:Morganamilo]] suggested to use README links instead of descriptions, but I'm not sure how that would pan out. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]])
 
 
 
:[[User:Larivact/drafts/Template:RespCell]]. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 07:50, 2 December 2018 (UTC)
 
 
 
::Thanks, it looks nice on my screen (1366x768): [http://i.imgur.com/chqzSvT.png] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:42, 2 December 2018 (UTC)
 
 
 
:::That CSS only takes affect if your browser width is below 600px. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 14:51, 2 December 2018 (UTC)
 
 
 
::::So much for placebo effect... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:09, 2 December 2018 (UTC)
 
 
 
:::::Yeah I was a bit confused by your response. Just to clarify tables need to be marked up differently for this to work, you can see an example in my draft. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:20, 2 December 2018 (UTC)
 
 
 
::::::Closing this as there does not appear to be any interest. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:38, 22 December 2018 (UTC)
 
 
 
== <s>Restore sections</s> ==
 
 
 
I seriously dislike [[Special:Diff/557837]] because it makes the page less accessible and is semantically wrong. You should be able to link any section you like, it is the job of the users to look around when they were linked to a specific section. I think we neither can nor should attempt to make our articles idiot-proof by substituting sections with definition terms.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 08:01, 2 December 2018 (UTC)
 
 
 
:The only way to make it idiot proof is to either delete this article or make it an alphabetical list - both of which are still very tempting to me. In any case, I don't think the separated tables (with sections or with definition terms) are ideal either - it's only there because pacman wrappers are broken to such an extent they need to be specifically warned against. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:44, 2 December 2018 (UTC)
 
 
 
:One thing to keep in mind (and the reason for this "special treatment") is that the [[AUR helpers]] article is systematically abused to encourage help vampirism (resp. encouragement to ignore supported distribution tools) by users alike. I've restored the sections for now, but adding {{ic|<nowiki>__NOTOC__</nowiki>}} should be a consideration. It won't prevent copy pasting of links but might at least force the "AUR helpers are not supported" warning into view. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:54, 2 December 2018 (UTC)
 
 
 
::[https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=558612&oldid=558121], closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:40, 8 December 2018 (UTC)
 
 
 
== <s>Remove "optional" distinction from File review</s> ==
 
 
 
The description already says "by default", and I have no idea why we should encourage the notion of do-not-review-unless-opt-in. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:30, 8 December 2018 (UTC)
 
 
 
:Yes, please change this. It's anyways describing a supported feature, the implication is that most tools likely offer you the ability to skip past. Also we can just remove the column entirely from the "search & download" helpers, surely... or mark them as not applicable rather than "yes". -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 05:52, 9 December 2018 (UTC)
 
 
 
::Done & done. - [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 9 December 2018 (UTC)
 
 
 
:::Wait, are all these helpers don't-review-by-default? -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:23, 9 December 2018 (UTC)
 
 
 
::::Yes. (I tested the bunch of them back in the day, and I don't know of any changes since then.) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:22, 9 December 2018 (UTC)
 
 
 
== <s>Remove pacaur</s> ==
 
 
 
See [https://lists.archlinux.org/pipermail/aur-requests/2018-December/028524.html request]. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 11:58, 15 December 2018 (UTC)
 
 
 
:It's not like we remove any other helper projects that are basically dead but still exist and still have users. No matter how ill-advised it may be to use a helper which doesn't have support from the author anymore. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 16:36, 16 December 2018 (UTC)
 
 
 
::Other TU has fulfilled package deletion request, so I removed pacaur from the article as well. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:10, 20 December 2018 (UTC)
 
 
 
::: Thanks! -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 12:11, 24 December 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)