Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
(answer why pacaur is still supported)
 
(291 intermediate revisions by 22 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.
  
== Native pacman revisited ==
+
[[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 18:14, 25 July 2019 (UTC)
  
As a follow-up to [[#Expand_Secure_criteria_to_include_other_.28non-PKGBUILD.29_bundled_files]], the way "Native pacman" is used is misleading, since it depicts wrapping {{ic|pacman}} as a generally positive thing. This contradicts the warning bundled with the criteria, as well that using the same syntax for official and user-submitted packages blurs the lines between packages that are supported, and packages that might arbitrary broken things; latter requiring careful attention before installation.
+
:Thanks: [[Special:Diff/578024]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:46, 25 July 2019 (UTC)
  
I see some alternatives:
+
== Update information on rua? ==
  
* <s>Remove the column and move any entries that go against it to "problematic". The description of [[AUR_helpers#Discontinued_or_problematic]] would be adapted accordingly.</s>
+
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)
* Keep the column but remove Green/Grey colors, potentially renaming both the column and its entries.
 
  
There's benefits in both approaches but implementing the first is less effort. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:21, 14 July 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)
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:21, 14 July 2018 (UTC)
 
  
:I think the second approach is best since it offers more information/overview over the first. I propose the following changes:
+
::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)
:*Native pacman -> Pacman wrapping (restore the original column name)
 
:*Yes [Green] -> ''Literal'' '''[Grey]'''
 
:*N/A [Grey] -> ''None'' [Grey]
 
:*Partial [Yellow] -> ''Modified'' [Yellow]
 
:*No [Red] -> ''Faulty'' [Red]
 
:-- The color change would basically reflect the old "Syntax" column, which deliberately had no colors. See [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&oldid=423597#Pacman-like_Syntax]. [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:46, 21 July 2018 (UTC)
 
  
::Works for me. I'm guessing the criteria will remain the same? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 23:16, 21 July 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)
  
:::Yeah, unless someone brings new arguments to the table. I'll probably make some minor changes to fit the new wording. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:19, 21 July 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)
  
:::Actually, thinking about it how about faulty -> harmful? To me faulty kind of implies it's bugged out. While -Udd and such are usually purposely implemented. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 23:25, 21 July 2018 (UTC)
+
== pacaur is also discontinued ==
  
::::I'm not sure, since a red entry on clean build/secure is just as harmful. I guess the latter are not done "on purpose" but due to negligence, unlike -Udd and friends as you mentioned.
+
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)
::::Another point is whether to leave the column in place, or move it back to the end like the previous "Syntax" column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:46, 23 July 2018 (UTC)
 
  
:::::I'd argue clean build is not harmful. There is no real harm to a failed build, just inconvenience. Insecure is harmful but I believe 'insecure' reflects that.
+
: 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)
:::::I don't see a need to move the column as it still may contain red and yellow so it's not too out of place in between all the colored fields. Then again I have no complains against moving it either really.
 
:::::[[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 17:11, 23 July 2018 (UTC)
 
 
 
::::::I experimented a bit with [[User:Svito/Deleteme]], I like proposal with some changes:
 
::::::* Rename criteria to ''Pacman wrapper'' - for consistency with ''Reliable parser'' and ''Reliable solver''
 
::::::* ✓ ''Yes'' - no color, table is colorful enough as it is, other columns being colorful already indicates they are different in nature so change to ''Literal'' is not requried
 
::::::* ✓ ''N/A'' - no color, create [[Template:-]], use <s>em</s> dash to make it instantly distinguishable from ''Yes'' and other entries
 
::::::* ✗ ''Modified'' - yellow
 
::::::* ✗ ''Harmful'' - red, this column is otherwise colorless so having extra emphasis would not hurt, other columns have color to compliment yes/no
 
::::::* ✓ move column to the left of ''Secure'' instead to preserve 3 major criteria group as well as have colorful grouping
 
::::::* ✓ use [[Template:C]] for centered entries instead of longer string
 
::::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:57, 24 July 2018 (UTC), updated 10:00, 26 July 2018 (UTC)
 
 
 
:::::::I agree with all these changes apart that I'm not sure yet on the "Harmful" wording and that the emdash is a bit too long for my taste. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:22, 24 July 2018 (UTC)
 
 
 
::::::::[https://wiki.archlinux.org/index.php?title=User:Svito/Deleteme&diff=530866&oldid=530841] looks like a good approach since it immediately tells what's wrong instead of throwing fancy terms around -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:07, 24 July 2018 (UTC)
 
::::::::edit: I think yaourt did some more things besides splitting -Syu, like manual database manipulation (!), but I'd need to check this again -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:08, 24 July 2018 (UTC)
 
 
 
:::::::::Yep: [https://github.com/archlinuxfr/yaourt/blob/master/src/lib/alpm_backup.sh#L38] It writes back the local pacman db with some mangled version. If you want crazy, look no further than yaourt. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 00:29, 26 July 2018 (UTC)
 
 
 
::::::::::Thanks for doing research on this as I had trouble with reading yaourt source myself. I have merged major discussed changes to the table but did not change column names. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:33, 26 July 2018 (UTC)
 
 
 
:::::::::::Nice work. I ran out of tacos so here's a [https://images-na.ssl-images-amazon.com/images/I/81BLwVPEAEL._UX466_.jpg fancy hat] instead.
 
:::::::::::I agree ''Pacman wrapper'' is a better name so I'll probably change it in the next few days unless there's objections. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:30, 26 July 2018 (UTC)
 
 
 
::::::::::::Now that it's called "Pacman Wrapper" it makes sense to have "No" instead of the dash don't you think? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 17:55, 28 July 2018 (UTC)
 
 
 
:::::::::::::It is not necessary feature but "nice to have" for a helper so I do not think change is needed here. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 18:02, 28 July 2018 (UTC)
 
 
 
::::::::::::::I agree but isn't that the reason it's not colored? My intention was to have it as "No" but keep it grey. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 18:07, 28 July 2018 (UTC)
 
 
 
:::::::::::::::It is same way as for ''Batch interaction'' and ''Shell completion'', we don't use Yes/No there because there are multiple options, but with neutral dash for ''No''. Whole point of this change is to have helpers that act as pacman wrapper clearly seen and those who do not not discriminated with ''No'' which is used in table to note lack of features or broken features. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 18:14, 28 July 2018 (UTC)
 
 
 
::::::::::::::::There's a slight discrepancy though, in that {{ic|-}} is used when "is feature X ''well-implemented''" does not apply due to not having feature X in the first place. "Pacman wrapper" on the contrary says "Does it have feature X?"; compare how neither ''Batch interaction'' nor ''Shell completion'' have {{ic|Yes}} as entries, but shells and numbers, respectively.
 
::::::::::::::::Not sure on the best solution, in the shell completion sense you could change the column to ''command wrapper'', but since there's no other relevant commands but {{man|8|pacman}} to wrap that makes no sense either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:22, 4 August 2018 (UTC)
 
 
 
:::::::::::::::::I agree, hope [[Special:Diff/534929/next]] makes it more clear and avoids it looking like another Yes/No question. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:13, 18 August 2018 (UTC)
 
 
 
::::::::::::::::::Not sure that's the best way to put it, since the only ''compliant'' pacman wrapper is one that doesn't wrap pacman at all, by the warning in the criteria. Perhaps we should choose a different approach entirely, and add some general column that warns on potential harmful behavior. This would be comparable to the "Notes" column in the GUI section. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:21, 19 August 2018 (UTC)
 
 
 
=== <s>on the evils of yaourt</s> ===
 
 
 
Can we try to be at least slightly fair when making fun of yaourt? Any user using the option "--backup: Backup or restore alpm local database. See Backup Options." is definitively requesting to write back a new alpm database, which is a far cry from your accusation which implies it just does so with the drop of a hat, moreover your implication that it does so with a "mangled" version which is simply entirely untrue (as this is no more or less mangled than any other old version). I cannot really imagine why I'd want to restore an old alpm database rather than fix the new, without throwing up my hands in despair and reverting to a complete backup of {{ic|/}}, but that's just arguing that the option is useless, not that it's a dangerous, crazy way to implement the dubious functionality in the first place.
 
 
 
I get that it's fun to mock yaourt, but I'm perpetually shocked that even most competent people rarely manage to mock yaourt in a competent manner. There's definitely what to be mocked about yaourt, how about you mock that instead?
 
 
 
-- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 03:17, 29 July 2018 (UTC)
 
 
 
=== Split pacman wrappers ===
 
 
 
Please review this proposal, compiled from [[#Native pacman revisited]] discussion and [[User:Svito/AUR helpers]] contributions:
 
 
 
* split ''#Active'' section/table into ''#AUR only'' and ''#Pacman wrappers''
 
* order sections by increase of functionality: ''#Search and download only'' -> ''#AUR only'' -> ''#Pacman wrappers''
 
* move pacman criteria inside the ''#Pacman wrappers'' section
 
** ✗ add more warning text: [[Special:Diff/536696/next]]
 
* move helpers from ''#Discontinued and problematic'' into above tables, add <small>'''(discontinued)'''</small> next to package name and color name cell grey
 
:As there is a difference between what subset of features abandoned helpers implement I think it is more appropriate to put them into comparison to other helpers implementing similar functionality and share warning notes in case of pacman wrappers that do not apply to other helpers.
 
 
 
-- created 02:08, 23 August 2018 (UTC), last edited -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:47, 23 August 2018 (UTC)
 
 
 
:On the separate points:
 
:*I'd wait for more opinions on [https://wiki.archlinux.org/index.php?oldid=536696&diff=next], or reword it to be less pedantic/more formal. There's also exception cases like {{AUR|naaman}}, which uses pacman syntax for operations restricted to AUR, or even {{AUR|yaourt}} which flashes a big warning whenever you try to install an AUR package.
 
:*The criteria and "bad wrap" column might also need some adaptations to the new structure. I'd consider dropping the criteria entirely and leaving the warning in place, because helpers like {{AUR|pikaur}} have shown that trying to be exhaustive is bound to failure.
 
:Essentially I'd go with the approach in [[AUR_helpers#Graphical]]: ''known'' derivations result in a helper getting a red entry, period. The previous criteria could be kept as "guidelines" and moved to the talk page, as they might be still useful to helper ''authors''. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:23, 23 August 2018 (UTC)
 
:-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:25, 23 August 2018 (UTC)
 
 
 
::I drop warning suggestion entirely for now and back to single line warning about potential to break the system. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:47, 23 August 2018 (UTC)
 
 
 
:::Sounds good. I would like to keep a reminder that these tools may, ''at any point'', add unsafe flags or break the system in other ways, though. After all these are third-party tools not audited by any arch or pacman developers, yet meant to replace {{man|8|pacman}} in one way or another. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:22, 24 August 2018 (UTC)
 
 
 
== <s>add back aurman</s> ==
 
 
 
[[Special:Diff/536043/next]], [https://github.com/polygamma/aurman/issues/259#issuecomment-414714208 github comment]: I am sorry to hear unfortunate news that [[User:Polygamma|Polygamma]] was overwhelmed by diverse user feedback and felt the need to discontinue the project. Despite author request we should probably not remove it completely from wiki but make it visible in discontinued section. As author deserves his peace, readers also deserve to know what happened to the project and I don't think that having it clear aurman is discontinued on the wiki would direct more hate towards the author and his project (at least I hope there are no such people willing to resort to that kind of waste of time). -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:47, 21 August 2018 (UTC)
 
 
 
:aurman is not discontinued or problematic. I'll still be developing it, but only for myself, which means that it has no place in the aur wiki. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:55, 21 August 2018 (UTC)
 
 
 
::Essentially, that issues have been disabled, and aurman will be developed according to Polygamma's whim. It will continue to work, and see whatever improvements Polygamma decides to implement himself, but no more <s>customer</s> user support will be provided. ;)
 
::Of course, anyone with an idea for implementation, who is willing to put in the time to code it themself and submit a pull request, will be evaluated on merit -- and such contributions are likely to be significant higher quality than the norm.
 
::-- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 21:13, 21 August 2018 (UTC)
 
 
 
:::Understandable. What about displaying it like on [[User:Svito/AUR helpers#Pacman wrappers]], at the bottom of the table, colored gray and "Not for public use" in Notes column? It is not like new readers will pick helper from the bottom of the table and will be complaining about it. But returning readers will not be confused by their favourite helper not being there. I think more readers should know that aurman is not developed for people who need any kind of support. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:43, 21 August 2018 (UTC)
 
 
 
:::: I guess I am fine with the grey entry at the bottom. Closed development sounds fine, too. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 22:57, 21 August 2018 (UTC)
 
 
 
:::::Cool, thank you for your time and effort! -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 23:02, 21 August 2018 (UTC)
 
 
 
== <s>customizepkg/ programmatic package customisation</s> ==
 
I wish to have added a column displaying if the AUR helper supports [https://github.com/Scimmia22/customizepkg-scripting customizepkg] or another/ an own way of programmatically changing packages before installation. This functionality should include that when doing an upgrade, and it is detected that the build should be modified with regard to the official package, the package should instead be built from source. Should apply to official Arch Linux packages and AUR packages and optionally also other (unofficial) repositories schould be supported.
 
 
 
(My use of customizepkg is with the flavour customizepkg-scripting, and I use it to build packages with own options, or with own patches to upstream surces, and I use it integrated into a system upgrade ("-Su"), it will show which packages are upgraded but have a customizepkg hook and instead of downloading the binary, it will be a customised built from source with the newest version)
 
 
 
yaourt does this but has some bugs, [https://aur.archlinux.org/packages/yaourtix-git/ yaourtix] fixes some of those bugs (but still depends on outdated yaourt).
 
 
 
[[User:Dreieck|Dreieck]] ([[User talk:Dreieck|talk]]) 10:10, 23 August 2018 (UTC)
 
 
 
:This is not a basic feature, but a specificity, much like building in chroots or using local repos. As such a separate column is not warranted. However, this functionality is already fulfilled by {{man|1|git}} (''Git clone'' column): local changes can be kept with {{man|1|git-commit}} and are applied through {{man|1|git-rebase}}.  
 
:The same applies to git helpers for the official repositories, like {{Pkg|asp}}, which are outside the scope of this article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:09, 23 August 2018 (UTC)
 
 
 
== proper batch interaction 2 and 3 ==
 
 
 
Is there even a way to implement this feature correctly?
 
 
 
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:
 
 
 
* copy sync db and perform sync on copied db, avoiding possible partial upgrades in the system
 
* 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
 
* {{ic|[user]}} batch queue updates and resolutions
 
* sync sync db with its copy and perform system upgrade
 
* perform other package operations in resolved order
 
* build and install AUR packages in resolved order
 
 
 
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:50, 26 August 2018 (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)
 

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)