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).

Multi-thread support

This also made me wonder if tools differentiate regarding multi-thread support (seems related, e.g. cower has a defaulted option for it). --Indigo (talk) 11:33, 3 April 2016 (UTC)

AFAIK, besides cower, packer [2] and bauerbill (download.sh amongst others) have multiple threads. aurutils also uses aria2c for downloads, if that counts.
The benefits of multiple threads are however not always clear:
* by my understanding, cower uses multiple threads, but with one query per package [3] (compare against multiinfo).
* More generally, tasks (like dependency solving) can be sped up by using different methods which need to be called less often
* Building packages would almost always be done sequentially: dependencies have to be installed (resulting in pacman locks), and there's -j in makepkg.conf anyway.
Regardless, there are some large differences in AUR helper speed (with bauerbill being ahead of the rest). But I'm not sure how to quantify this in the table ... -- Alad (talk) 12:31, 3 April 2016 (UTC)
Multi-thread support doesn't necessarily mean the helper is better. In cower case, multi-thread support was implemented before multiinfo was available in the RPC interface, and as of today using multiinfo is less complex and faster than using multiple info threads. Since it is difficult to implement multiinfo support without an important rewrite, cower multithreading is more a drawback than an advantage.
As for speed, it's indeed very hard to quantify in a meaningful manner. For example, pacaur dependency solver is slower than bauerbill's solver, but on the other hand it is designed to compute more stuff than other helpers up front in order to avoid bothering the user once the install process is started. --Spyhawk (talk) 13:42, 3 April 2016 (UTC)
Interesting. Actually, I did not want to induce a "speed" column, rather the opposite. As you both say, always very difficult to choose a fairly universal/comparable benchmark, so "speed" as such is better be left out of comparison (as a column). If one wants to mention it, it might be useful to have a general remark at the top of the table, or somewhere else in the article, quoting some of the influencing factors you name; perhaps linking to (re -j) Makepkg#MAKEFLAGS and (re Skyhawk's remark above) Makepkg#Improving compile times. --Indigo (talk) 14:01, 3 April 2016 (UTC)

Yaourt seems to do safe stuff now

Can someone explain to me why yaourt is unsafe? Reading the offending lines, it sources something, but I threw a PKGBUILD at it which executes subshells in the variables if let run, and nothing got executed before I gave explicit permissions. Even the mentioned -Si did not produce the expected result. I'm going to change this to safe for now until someone can produce a reliable test case which does execute something malicious. Dustball (talk) 13:07, 4 September 2016 (UTC)

Yaourt is not safe by the definition of the source column:
does not source, by default, the PKGBUILD at all, or, before doing so, reminds the user and offers him the opportunity to inspect it manually.
Yaourt's definition of "safe" is running the PKGBUILD through a large sed filter before sourcing it. [4] See [5] why this is a flawed approach (e.g., their filter ignores tilde expansion). Besides, it's not because you don't have an immediate test-case for executing code that we should mark it as "safe" and ignore the table description; that's just misleading.
If you want a green entry for yaourt, talk to upstream for using the AUR RPC like everyone else does since 2012. Closing. -- Alad (talk) 14:15, 4 September 2016 (UTC)