Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
(→‎Legend editions: re, close)
 
(264 intermediate revisions by 20 users not shown)
Line 1: Line 1:
== "Reference" implementation ==
+
== <s>Legend editions</s> ==
  
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.
+
:::Agreed. What about the following style:
::: 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)
+
::::The [[#Comparison tables]] columns have the following meaning:
 +
::::;Major feature columns:
 +
:::::*''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.
 +
::::;File review: Does not [[source]] the PKGBUILD at all ''by default''; or, alerts the user and offers the opportunity to inspect the PKGBUILD manually before it is sourced. Some helpers are known to source PKGBUILDs before the user can inspect them, '''allowing malicious code to be executed'''.
 +
::::...
 +
::::;Shell completion: [[w:Command-line_completion|Tab completion]] is available for the listed [[shell]]s.
 +
::::;Specificity:
 +
:::::*''Batch interaction'' indicates the ability 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.
 +
:::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:20, 2 December 2019 (UTC)
  
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
+
::::Merged as conclusion to discussion: batch interaction now belongs to Specificity as separate column long gone, so legend changed accordingly; added list inside optional/partial note. Closing discussion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:56, 12 January 2020 (UTC)
  
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
+
== <s>Add yup to Pacman wrappers</s> ==
  
The new criteria would be as follows:
+
Links:
* PKGBUILD, no other files -> Partial
+
[https://github.com/ericm/yup github] {{AUR|yup}}
* 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)
+
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.
  
: 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)
+
Pros:
  
: "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 fetches pgp keys for you.
: 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)
+
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.
  
:: 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.
+
[[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 14:52, 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)
+
: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)
  
:::: 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)
+
:: 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 guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 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)
  
:::::: 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)
+
:::: 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)
  
== proper batch interaction 2 and 3 ==
+
:::::Since it uses ncurses I would rather suggest to include it as TUI in #Graphical section instead. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 23:11, 1 December 2019 (UTC)
  
Is there even a way to implement this feature correctly?
+
::::::Done. Closing. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 00:50, 12 January 2020 (UTC)
  
I do not know much so correct me if I'm wrong but the proper way to do {{ic|2}} and {{ic|3}} for something like {{ic|wrapper repopkg aurpkg}} seemingly is:
+
== <s>Update information on rua?</s> ==
  
# copy sync db and perform sync on copied db, avoiding possible partial upgrades in the system
+
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)
# find {{ic|repopkg}} and {{ic|aurpkg}} using copied sync db and AUR backend respectively
 
# {{ic|[user]}} package confirmation
 
# get all AUR package files of {{ic|aurpkg}} and its AUR deps
 
# {{ic|[user]}} batch inspection
 
# loop: if new AUR deps introduced get package files for those too and do another batch inspection
 
# calculate solutions using up-to-date copy of sync db
 
# {{ic|[user]}} batch queue updates and resolutions
 
# <s>sync sync db with its copy and</s> perform system upgrade
 
## calculate solutions again with sync db (if sync db is different from its copy)
 
## {{ic|[user]}} batch queue updates and resolutions again (if solutions are different)
 
# perform other package operations in resolved order
 
# build and install AUR packages in resolved order
 
  
-- 13:50, 26 August 2018 (UTC), last edited -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:43, 26 August 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)
  
: For 2/ the biggest pitfall to avoid  is to calculate the solution for AUR deps on the basis of completely updated repo packages, not on the basis of the currently installed packages (f.e., the way it is done in yaourt can lead to some issues. From what I've seen, all of the other helpers (aurman, pikaur, yay) have some issues in their latest iterations with 2/, though aurman does better than the rest). -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:27, 26 August 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)
  
::I agree. Maybe it is not clear but I assumed points 1-8 have to be done with up-to-date copy of sync db, not sync db and not local db (both of which remain unchanged up to point 9). -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:08, 26 August 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)
  
::: Good then. This said, your solution above seems a bit over complicated to me (f.e. points 6 that should be done in 5, or 7 that should be done before 4), but I might miss something since I have never implemented batch interaction 2/ myself - I rejected the idea because of its complexity. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:26, 27 August 2018 (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. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 16:12, 12 September 2019 (UTC)
  
== Show which unsafe flags are used by default ==
+
:::::Local patch application added as confirmed "uncontroversial" on IRC. Shellcheck rejected as "controversial/trivial". Closing. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:17, 12 January 2020 (UTC)
  
Batch interaction has the qualifier: An asterisk denotes functionality specifically enabled by the user.
+
== <s>pacaur is also discontinued</s> ==
  
The unsafe flags column should also do this to show what is and is not enabled by default.
+
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)
  
There's also other solution's such as "-Sy (enabled by --foo)", but that would probably make the column annoyingly long. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]])
+
: 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)
  
: See [https://wiki.archlinux.org/index.php/User_talk:Svito/AUR_helpers#unsafe_flags_column_position]. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:20, 27 August 2018 (UTC)
+
::You meant https://github.com/E5ten/pacaur to be second link probably. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 00:15, 2 December 2019 (UTC)
  
::In short, 1. I didn't like how asterisks or "optional" looked 2. it's arguably not very important anyway. Open to suggestions though, as long as it's reasonable in terms of column length (see the discussion above on small screens). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:00, 27 August 2018 (UTC)
+
== <s>Drop "Clean Build" Column</s> ==
  
::: There is also the option of removing the asterisk in Batch interaction. It's even less important here than in the Unsafe flags column. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 16:23, 27 August 2018 (UTC)
+
Literally every helper apart from yaourt has this as yes. Perhaps yaourt's variable exporting should be listed under specificity or the "Unsafe Flags" column could be adjusted to unsafe actions? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 04:54, 14 September 2018 (UTC)
  
::::[[Special:Diff/538051/538105|Another option]] is to merge both columns and indicate what unsafe flags used for what. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:57, 27 August 2018 (UTC)
+
:Disagree, since it's a reminder to anyone writing (existing and new) helpers. Example: [https://github.com/AladW/aurutils/pull/448] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:52, 14 September 2018 (UTC)
  
:::::IDK, looks messy to me, besides that unsafe flags are not necessarily linked to batch interaction (e.g., pacman -Ud). For my part I don't mind removing the "optional"/asterisks altogether and just let the user click the myriad of links we've provided. (Not sure what happened to the links in the ''batch interaction'' column) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:01, 27 August 2018 (UTC)
+
::Revisiting this topic, as 1. {{ic|makepkg}} related variables are listed under {{ic|ENVIRONMENT}} in {{man|8|makepkg}} and 2. custom logic that reimplements makepkg's configuration parsing (to e.g. append values such as PKGDEST) is more fragile than simply exporting these variables where required. That said, I guess there should remain some mention for {{ic|yaourt}} since it takes this idea to the literal extreme and apparently exports every single variable defined in {{ic|makepkg.conf}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:08, 1 December 2019 (UTC)
  
::::::I tried again with just asterisks, br tags and no commas [[Special:Diff/538110/538120|here]]. I think we should have "optional" notation in those 2 columns as it was considered an improvement when helper has made this behaviour optional and not default and scored higher in the table. It sounds to me like a considerable detail to have documented. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:57, 28 August 2018 (UTC)
+
:::And I had already removed both the column and yaourt. I must be living in the past. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:13, 1 December 2019 (UTC)
 
 
:::::::As far as I'm concerned, optional behavior in the unsafe flags column does not have to influence ranking anymore. All technical considerations aside, some authors have adopted optional flags not because they agreed with this practice, but because the AUR helper article is treated as some kind of religious object.
 
:::::::It's easier to assume that any pacman wrapper is broken by design - as hinted to by the warning - and use the unsafe flags as an enumeration of known problematic behavior. This is again similar to [[AUR helper#Graphical]]. That said, I have no real objections against [[Special:Diff/538110/538120]] either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:22, 28 August 2018 (UTC)
 
 
 
::::::::Merged with [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=538151&oldid=538003]. That leaves the alphabetical sorting. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:48, 28 August 2018 (UTC)
 
 
 
:::::::::I am worried with how powerful this article have become in affecting popular opinion, [[User:Kitsunyan|Kitsunyan]] may get too much of user feedback of kind yay or aurman authors have received so far possibly by being in that forever cursed top spot, and for sole author of pakku that may be too much to handle. yay is probably better fit to be in top position for now in my opinion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:44, 28 August 2018 (UTC)
 
 
 
::::::::::I guess we can wait until aura v2.0 is released. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 28 August 2018 (UTC)
 
 
 
:::::::: Yes, fully agree. I'm also pretty sure some of the optional flags will change as default in the not-so distant future. The asterisks look fine, I guess the important point was to remove the colours, as frankly that is what is decisive for user choice. Helper users are a very simple beast... Lastly, thanks to both of you and anyone else involved for that deep rework. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:56, 28 August 2018 (UTC)
 
 
 
== Showing AUR comments as an important point for AUR helpers ==
 
 
 
(First, sorry that I modified the page without starting this discussion first and thank you Svito for answering kindly).
 
 
 
Some AUR pkgbuilds are sometimes broken and require user intervention to repair them or, more importantly, the pkgbuild is flawed, so using it as-is can be bad for the system (see qwence comment on 2018-07-08 05:01 in acroread [https://aur.archlinux.org/packages/acroread/]). Such information is usually available in the comments, so showing them help building the package and can improve security.
 
Not to mention the packages that require importing GPG keys for which the author has a pinned comment to warn about it.
 
 
 
I don't think it should be mentioned as just a specificity of the AUR helper, but emphasized as a key feature and given its own column in the table.
 
 
 
{{Unsigned|15:21, 5 September 2018 (UTC)|Getzze}}
 
 
 
: I am strongly inclined to delete all those comments about PGP wherever I see them. Understanding how makepkg works is '''''not optional''''' and this is described on the [[makepkg]] article already. People who still don't know how to handle a PGP issue should not be allowed to use the AUR, really, but enforcing that is... problematic.... Either way, there is enough learned helplessness already without actively encouraging people to think that sort of behavior is not just okay, but expected and standardized upon.
 
 
 
: Relying on other people leaving comments is ''not'' a security replacement for reading the PKGBUILD before building it. It's actively bad for the community to emphasize these comments for this reason, as it encourages people to think that "the package is safe as long as my AUR helper doesn't show any comments".
 
 
 
: I see no reason to rank the helpers based on this meaningless statistic, and I disagree in the strongest terms against this change. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:39, 5 September 2018 (UTC)
 
 
 
== Pacman wrappers Specificity ==
 
 
 
I wanted to introduce the ''manual AUR package selection'' specificity for pacman wrappers. For example '''yay''' and '''pakku''' only allow {{ic|-Syu}} where they update system packages and AUR packages at the same time. '''pikaur''' when doing {{ic|-Syu}} also updates system packages and AUR packages at the same time but prompt user for manual selection for AUR packages, because for example I want to update to the new version of X program but not the Y lib (AUR) that is used only by Z program (AUR) so until Z is not updated I don't want to update Y. And '''yaourt''' when doing {{ic|-Syu}} updates only system packages, {{ic|-Syu --aur}} is needed for updating AUR packages as well, and a manual selection for AUR packages is available. That's why I wanted to introduce the ''manual AUR package selection'' specificity. -- [[User:Noraj|Noraj]] ([[User talk:Noraj|talk]]) 11:16, 9 September 2018 (UTC)
 
 
 
:Why just not specify {{ic|--ignore ''ylib''}}? It is problem with ''zprogram'' if it does not use versioned deps and allows library update that breaks it. Helper should just fail to satisfy AUR deps in correct case, bail out and user should specify {{ic|--ignore}} manually explicitly IMO.
 
:Additionally '''yay''' asks you what AUR packages to not upgrade that also provides solution to this [[w:XY problem|XY problem]].
 
:All-in-all if you can no longer build some package from AUR correctly because of dependency update that package is broken and should be fixed or be removed instead. And helpers should ideally not provide workarounds for problems that broken package introduce.
 
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:06, 9 September 2018 (UTC)
 
 
 
::It's not really about broken programs. It could just as easily apply to some package that you're sure will compile fine, but you also remember takes 45 minutes to build, which you don't want to spend right now.
 
 
 
::Also I really don't consider using versioned deps, to be the correct case. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 14:45, 9 September 2018 (UTC)
 
 
 
:::That's exactly my use case. Whether to allow it as a specificity or not? I'd probably say sure. But I also think there should be a cap on how many specificities an entry may have. I'd say max 4 or 5, otherwise the column may as well be called feature list. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 14:57, 9 September 2018 (UTC)
 
 
 
== Baseline AUR helper features ==
 
 
 
Some proposals about section names:
 
* ''Search-only'' -> ''Fetch only''
 
* ''Build and search'' -> ''Fetch and build''
 
* change introduction sentence
 
** from: Most helpers automate the process of retrieving a package's [[PKGBUILD]] from the AUR and building the package.
 
** to: AUR helpers provide functionality of searching for packages in [[AUR]] and fetching their [[PKGBUILD]]s. Some helpers additionally automate build and install process.
 
 
 
Also about {{AUR|package-query}}. I can't check now because github is down but if it does not retrieve PKGBUILDs (judging from ''N/A'' under ''Git clone'' column) shouldn't it be under ''Libraries''? Why does it qualify as AUR helper?
 
 
 
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:04, 11 September 2018 (UTC)
 
 
 
:Renames I like, although {{AUR|package-query}} is truly search only. The points in the intro are definitely better, the grammar is a little messed up though.
 
:{{AUR|package-query}} Works as a command line tool. Libraries would be #included or the language's equivalent.
 
: [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 21:15, 11 September 2018 (UTC)
 

Latest revision as of 01:57, 12 January 2020

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)
Agreed. What about the following style:
The #Comparison tables columns have the following meaning:
Major feature columns
  • 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.
File review
Does not source the PKGBUILD at all by default; or, alerts the user and offers the opportunity to inspect the PKGBUILD manually before it is sourced. Some helpers are known to source PKGBUILDs before the user can inspect them, allowing malicious code to be executed.
...
Shell completion
Tab completion is available for the listed shells.
Specificity
  • 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.
-- Svito (talk) 01:20, 2 December 2019 (UTC)
Merged as conclusion to discussion: batch interaction now belongs to Specificity as separate column long gone, so legend changed accordingly; added list inside optional/partial note. Closing discussion. -- Svito (talk) 01:56, 12 January 2020 (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)
Since it uses ncurses I would rather suggest to include it as TUI in #Graphical section instead. -- Svito (talk) 23:11, 1 December 2019 (UTC)
Done. Closing. -- Svito (talk) 00:50, 12 January 2020 (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)
Local patch application added as confirmed "uncontroversial" on IRC. Shellcheck rejected as "controversial/trivial". Closing. -- Svito (talk) 01:17, 12 January 2020 (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)
You meant https://github.com/E5ten/pacaur to be second link probably. -- Svito (talk) 00:15, 2 December 2019 (UTC)

Drop "Clean Build" Column

Literally every helper apart from yaourt has this as yes. Perhaps yaourt's variable exporting should be listed under specificity or the "Unsafe Flags" column could be adjusted to unsafe actions? Morganamilo (talk) 04:54, 14 September 2018 (UTC)

Disagree, since it's a reminder to anyone writing (existing and new) helpers. Example: [1] -- Alad (talk) 10:52, 14 September 2018 (UTC)
Revisiting this topic, as 1. makepkg related variables are listed under ENVIRONMENT in makepkg(8) and 2. custom logic that reimplements makepkg's configuration parsing (to e.g. append values such as PKGDEST) is more fragile than simply exporting these variables where required. That said, I guess there should remain some mention for yaourt since it takes this idea to the literal extreme and apparently exports every single variable defined in makepkg.conf. -- Alad (talk) 21:08, 1 December 2019 (UTC)
And I had already removed both the column and yaourt. I must be living in the past. -- Alad (talk) 21:13, 1 December 2019 (UTC)