Talk:AUR helpers

From ArchWiki
(Redirected from Talk:Yaourt)
Jump to: navigation, search
Note: Moderation — If your AUR helper does partial upgrades without explicit user intervention (i.e, specifying -Sy on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- Alad (talk) 09:37, 20 September 2015 (UTC)

Comparison table - build directory

Considering /tmp is mounted as tmpfs on Arch, and the potential downsides from building in RAM (running out of space), I think a column with the default build location for various helpers would be helpful.

The default values I've garnered so far, assuming TMPDIR is not set:

  • aurutils: $XDG_CACHE_HOME
  • pacaur: $XDG_CACHE_HOME (changed from /tmp, see [1])
  • bauerbill: $PWD/build
  • pkgbuilder: $PWD, /tmp when specified with -S
  • packer: /tmp (TMPDIR)
  • yaourt: /tmp (yaourtrc)

-- Alad (talk) 18:16, 1 April 2016 (UTC)

Yes, this could be useful. Although you'd want not to use color here, since users that know what they're doing would prefer to use /tmp (or setting up BUILDDIR to /tmp). --Spyhawk (talk) 11:15, 3 April 2016 (UTC)
+1. see also #Multi-thread support. --Indigo (talk) 11:33, 3 April 2016 (UTC)
Well, while it does have benefits for some users, it's still a bad default. As you say though, this is easy enough to change either way, unlike any of the behaviour described in the other columns.
We could leave out the colors, but mention the drawbacks/benefits in the "meanings" paragraph. -- Alad (talk) 13:35, 4 April 2016 (UTC)
It is bad default because some users have no idea about what they are doing, but this is strictly related to user preferences. Adding the meaning instead of colors sounds like the perfect solution to me. --Spyhawk (talk) 14:35, 4 April 2016 (UTC).

Reliable Updater

Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.

ie: Does it handle accurate update status on VCS packages? Does it handle accurate update status when developer fails to update .SCRINFO?

And any other unmentioned situations. Cody Learner (talk) 18:49, 22 February 2018 (UTC)

The second is an issue only pacaur has, by design to "improve metadata on the AUR". It has nothing to do with what an AUR helper should do. The first is at best a specificity, since the AUR has no perception of what a VCS package is. See FS#56602. -- Alad (talk) 20:02, 22 February 2018 (UTC)
I think the most important here to provide reliable testcase to prove the reliability of updater :-) I would suggest mb creating a repo a with some stub PKGBUILDs which could be used as testcases for criterias in the table. Actionless (talk) 20:19, 22 February 2018 (UTC)
Not sure what a testcase of such would look like, since scoring on the other criteria should guarantee reliable updates apart from some pecularities outlined above.
About the second case, it has been suggested before to create some centralized place for testing helpers instead of a few arbitrarily chosen AUR packages. However, since AUR helpers are (by definition) for the AUR, I wonder how you'd go about testing these helpers with an external repository. PKGBUILDs specifically made for testing helpers would not be accepted on AUR anyways as too specific. -- Alad (talk) 22:30, 22 February 2018 (UTC)
And what about adding packages to AUR but with some special prefix in package name (`_stub-package-test-reliable-solver`) and very explicit description ("DON'T INSTALL ME. Stub package intended for testing AUR helpers for 'reliable solver' criteria.") and so on? Actionless (talk) 23:53, 22 February 2018 (UTC)
Considering AUR helpers are something that's tolerated instead of supported, I doubt such packages explicitely targeting them with no use otherwise would have a long lifetime. -- Alad (talk) 12:00, 23 February 2018 (UTC)
See #"Reference" implementation for an alternative. -- Alad (talk) 13:29, 8 March 2018 (UTC)
I would argue this is covered by the new "Pacman wrap" column. That said there's some strange cases (e.g. rakudoAUR or nvidia-betaAUR) which some helpers can install successfully but fail to update afterward. Usually this involves version requirements (though note FS#54906). -- Alad (talk) 22:31, 18 March 2018 (UTC)

Default sorting for entries

Right now, entries are sorted alphabetically and can be sorted by column by clicking on the respective arrows. I propose to make the default sorting both alphabetically and by "less crap", so people don't have to wade through mixes of red and green. -- Alad (talk) 16:45, 5 March 2018 (UTC)

Agree, but is this possible to sort by default? See MediaWiki doc. I get a nice result by clicking twice on each column, starting from the last to the first one ("git clone" to "maintenance"). -- Spyhawk (talk) 00:35, 6 March 2018 (UTC)
It appears this has to be done manually: w:Help:Sorting#Initial_sort_order_of_rows. I do like the proposed order. -- Alad (talk) 13:19, 8 March 2018 (UTC)
[2] -- Alad (talk) 21:33, 18 March 2018 (UTC)

"AUR repo diff"

[3] no idea what that's supposed to mean. If it's git diffs, half of the table supports those. -- Alad (talk) 07:59, 8 March 2018 (UTC)

yup, that means exactly that. i wasn't sure if it worth mentioning or not Actionless (talk) 12:24, 8 March 2018 (UTC)
when a helper supports git clone but not git diff, we could consider using Template:Y instead of Template:Yes for the git column. -- Alad (talk) 12:58, 8 March 2018 (UTC)
good idea Actionless (talk) 12:59, 8 March 2018 (UTC)

"Reference" implementation

This is an alternative to #Reliable_Updater. Instead of an arbitrary set of test packages, we could write up a "specification" on what a reliable AUR helper should do. This should also be more helpful for potential AUR helper writers who otherwise have to wade through complex, fully-featured AUR helpers.

I propose a minimal reference implementation with the following points:

  • No client-side workarounds for upstream limitations. In particular, a reference implementation does not need to score full points on split packages, as makepkg --pkg was removed with pacman 5.
  • Minimal language constructs in e.g. a scripting language like dash.
  • Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.

My initial plan was to keep such an implementation in a man page aurhelper(7) (hosted as part of aurutils), but we can consider including on a sub-page of this article. It could be then linked from the comparison table. Thoughts? -- Alad (talk) 13:28, 8 March 2018 (UTC)

Generally agree with the idea, but I don't think there is a way around a set of PKGBUILDs that could be used to test helpers in a local AUR instance. F.e., I wouldn't define a "reliable" helper that doesn't handle split packages well. Since helpers are tolerated rather than supported, upstream limitations of the AUR might be temporary or permanent, meaning the limitation would actually be in the helper itself (f.e. like regex support). Also, I'd use pseudo code for such a reference as the actual implementation itself doesn't matter, unless you'd like to write a new minimalist helper. Spyhawk (talk) 15:26, 8 March 2018 (UTC)
Apart from FS#56602, I can't think of a case where upstream opposed removing limitations, even if helpers directly benefited. cf. the regex support discussed in [4] or the exit codes finally introduced in makepkg 5.1 which made automatic building significantly easier imo. To me it seems that the main reason we have these AUR limations is due to the minimal interest of helper writers in contributing upstream, and upstream itself having different priorities. Not sure why former is the case, the PHP codebase may play part in it - at least it does for me.
You can keep dash close enough to pseudo-code, I guess less so if you want a complete example rather than exemplary code blocks. For the PKGBUILD set, I use this: [5] -- Alad (talk) 18:34, 8 March 2018 (UTC)
My understanding is that changes that aren't invasive will be accepted upstream, but otherwise might be rejected (see [6]). One prominent example that comes to mind is FS#48796. It's not really relevant anymore since x86 has been officially dropped, but the solution would involve duplicating DB tables on the server, which isn't trivial to implement/migrate. Many of the feature requests involve non-trivial code change, which is the main reason nobody pushed patches; I dislike PHP but the language itself isn't too hard either. For regex, see the bottom of [7], which is the follow-up of your link above.
Your testsuite seems interesting (thanks for the link), but one advantage of having a fixed set of packages is that these packages might be updated and change, making these edge cases difficult to test. This happened quite a few times with my own list of test packages in the past and this was rather annoying. Spyhawk (talk) 20:20, 8 March 2018 (UTC)

Add "pacman wrap" column

Since we have a Clean build column, I believe we should also have a "Pacman wrap" column that details how helpers wrap pacman (if applicable). A green entry should be reserved to helpers that only use pacman directly, while avoiding potentially harmful commands such as pacman -Ud or pacman -Rdd. A yellow entry could be for direct pacman use but including use of latter commands. A red entry would be for reimplementations through libalpm or other means. An N/A (grey) entry is used if no pacman wrapping is done in the first place.

The reasoning for this proposal is that while the table gives a good overview on helper features, it gives no indication whatsoever on potential harmful effects due to reimplementations of pacman. This is already having an effect on the support channels, where at best it makes debugging more difficult (see for example [8]), and having such a column might encourage future helper writers to avoid making this same mistake. -- Alad (talk) 02:59, 11 March 2018 (UTC)

For example in pikaur I do use -Rdd in one place: [9]
However I don't know any other possible way to handle the removal of conflicting package before installing its replacement with --noconfirm option.
But to avoid the problem on the further steps it's guarded with transaction: [10] so if something will fail that operation will be canceled.
Also it's not clear to me if there is any difference between pacman -Su and pacman -S $(pacman -Quq). Actionless (talk) 03:56, 11 March 2018 (UTC)
If pacman would have an option to not confirm about installing packages (:: Proceed with installation? [Y/n]) but confirm everything else (like conflicts and so on) that would actually solve the issue at all. Actionless (talk) 04:31, 11 March 2018 (UTC)
You can use the undocumented --ask flag (see pacman git log) or better, pacinstall --remove from pacutils which has the ability to install and remove packages concurrently. -- Alad (talk) 18:20, 12 March 2018 (UTC)
Thanks! Is there a similar way to avoid extra question in 'makepkg --syncdeps --rmdeps'?
UPD: i've also updated pikaur to avoid using --nodeps and --noconfirm. Actionless (talk) 03:33, 13 March 2018 (UTC)
I don't know, you can try passing --ask to makepkg I guess. -- Alad (talk) 20:58, 18 March 2018 (UTC)
I guess that's actually a good idea, I'd just like to include one more thing. That column should yield details about the behavior of that aur helper when using the helper without non native pacman flags. Surely I have something in mind why I say that: aurman flag --do_everything, which is a non native pacman flag, which is also being described in the readme as not recommended, but which may be used. it changes the behavior of aurman -Syu in the first place, so that would be a candidate for the "non-green" entry, but I bet there are other aur helpers out there, which by default only do sane things, but may be used in another way, when specifying any config options or command line flags. one could go one step further maybe: only if the aur helper specifies those side effects in the readme, man page or whatever, the aur helper gets a "green" entry. hence those side effects may only occur if the user uses a flag, whereas those side effects have been clarified enough Polygamma (talk) 15:39, 11 March 2018 (UTC)
Updated the table (nearly lost all my changes due to edit conflicts...): [11] Some notes:
  • The source code of naaman and yaourt was incomprehensible to me, but yaourt at least parses sync dbs by hand (yaourt -Q) and separates pacman -Syu to pacman -Sy && <stuff> && pacman -Su so it got a red entry.
  • yay got a red entry, see below.
  • pikaur got a red entry due to issues like [12], which while resolved, give no indication that pikaur started using pacman rather than a manual (py)alpm implementation. aurman got a green entry due to it only replacing pacman when the --do_everything flag is passed. Correct me if I'm wrong on either.
  • I was gratuitous with the N/A flag; e.g. cower uses libalpm(3) but it's not used as a pacman wrapper.
-- Alad (talk) 21:04, 18 March 2018 (UTC)
Also maybe the column should be renamed to something that better reflects Yes/No entries, like "Native pacman" or such. That or change the Yes/No entries to specific ones such as {{R|libalpm}}. Former should be simpler, since details can be explained in added links. -- Alad (talk) 21:14, 18 March 2018 (UTC)
If yay -Syu is in fact -Syyu, that sounds more like a "bug" that should be fixed. Has this been reported, or acknowledged and dismissed? Spyhawk (talk) 13:51, 13 March 2018 (UTC)
I'm not sure on the -Syy part, but in general, acknowledged and dismissed: [13] -- Alad (talk) 20:58, 18 March 2018 (UTC)