Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(Secure column in comparaison table: re)
(Comparison table - solver: new test-case: sign)
 
(161 intermediate revisions by 10 users not shown)
Line 1: Line 1:
Authors of each front end should post a short (2-3 line) description of their creation, along with a homepage link and an AUR link (where applicable). A link to a screenshot page would also be nice (if applicable).
+
{{Note|'''Moderation''' — If your AUR helper does [[partial upgrade]]s ''without explicit user intervention'' (i.e, specifying {{ic|-Sy}} on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 20 September 2015 (UTC)
 +
}}
  
== Secure column in comparaison table ==
+
== Comparison table - build directory ==
  
Description says "tries to protect the user", I don't know what "tries" means but if we take the default behavior of aur helpers marked as secure :
+
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.  
*owl remains on cower to download deps so, it doesn't source PKGBUILD but calls makepkg without further questions, so finally, PKGBUILD is sourced.
+
*aura does the same
+
*pbfetch sources PKGBUILD (even if it removes build ())
+
*pacaur sources PKGBUILD (it can be configured to remains on cower)
+
...
+
  
As far as I know, only cower is secure (it builds/installs nothing) and spinach (and pacaur with secure on) ask before calling makepkg.
+
The default values I've garnered so far, assuming TMPDIR is not set:
  
The only thing secure in dealing with AUR package is knowing what AUR is about.
+
* aurutils: $XDG_CACHE_HOME
 +
* pacaur: $XDG_CACHE_HOME (changed from /tmp, see [https://github.com/rmarquis/pacaur/commit/c5d750f75f040b21249fff100a2c8875348d03d1])
 +
* bauerbill: $PWD/build
 +
* pkgbuilder: $PWD, /tmp when specified with -S
 +
* packer: /tmp (TMPDIR)
 +
* yaourt: /tmp (yaourtrc)
  
[[User:Tuxce|Tuxce]] ([[User talk:Tuxce|talk]]) 12:50, 26 April 2013 (UTC)
+
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:16, 1 April 2016 (UTC)
: I think it only means asking the user to look and check PKGBUILD, especially for download URL. So it can be renamed to "Check PKGBUILD". -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 00:13, 27 April 2013 (UTC)
+
::My guess is that the "Secure" column is an adaptation of the "Manually Parses PKGBUILD*" column in [https://wiki.archlinux.org/index.php?title=AUR_Helpers&oldid=245047#Comparison_Table this old revision], see also the note at the bottom. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:50, 28 April 2013 (UTC)
+
:::Given that at the end, all AUR helpers (exept cower) call makepkg, PKGBUILD are sourced, so I think it should be removed. The word "secure" is just confusing.
+
:::For example, aurget can be considered more "secure" than owl or aura as it ask to review PKGBUILD before it being sourced.
+
:::[[User:Tuxce|Tuxce]] ([[User talk:Tuxce|talk]]) 20:05, 28 April 2013 (UTC)
+
::::Agreed, "Secure" without any kind of explanation doesn't mean anything. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:43, 29 April 2013 (UTC)
+
  
::::: "Secure" simply means the PKGBUILDs aren't sourced ***before*** the user has a chance to inspect the PKGBUILD himself. Makepkg does source the PKGBUILD obviously, it doesn't mean using it is insecure (but using it blindly is). For example, packer source the PKGBUILD before showing it to the user, unless the --preview option is passed. And so does pacaur (when using the bash solver), although the PKGBUILDs are scanned for potential malicious pseudo code using sudo. Spyhawk 12:07, 15 May 2013 (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). --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 11:15, 3 April 2016 (UTC)
  
::::::So, just to include also cower in the definition, I think a more correct formulation would be: ''"Secure means that the application, by default, doesn't source the PKGBUILD at all, or, before doing it, reminds the user and offers him the opportunity to inspect it manually"''.
+
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
::::::Note though that the inspection of a PKGBUILD is always a separate human operation that the user has to do deliberately, and it's independent of the helper being used; this means that every "secure" application can be used insecurely if the user doesn't inspect the PKGBUILD, and vice versa every "insecure" application can be used securely if e.g. the user inspects the PKGBUILD through the AUR website.
+
::: 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.
::::::Also, the "by default" clause is IMHO very important, in fact you could for example use packer with an alias that runs it with the --preview flag, thus making it a "secure" application, with just such a minimal change.
+
::: We could leave out the colors, but mention the drawbacks/benefits in the "meanings" paragraph. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:35, 4 April 2016 (UTC)
::::::By the way, I haven't used yaourt for a while, but IIRC it used to let the user review the PKGBUILD after downloading it; it's not clear why it's not considered secure.
+
 
::::::In the end, my opinion is that every application offers different degrees of security, and trying to sum all up in a Yes/No column is too simplistic: I would leave more verbose security considerations in the descriptions of every application above the table, or at least I would add some words in the "Specificity" column.
+
:::: 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. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:35, 4 April 2016 (UTC).
:::::: -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:41, 18 May 2013 (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). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
 +
 
 +
: AFAIK, besides cower, packer [http://kmkeen.com/multithreaded-bash/] and bauerbill ({{ic|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 [https://github.com/falconindy/cower/blob/master/cower.c#L667] (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 {{ic|-j}} in {{ic|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 ... -- [[User:Alad|Alad]] ([[User talk: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. --[[User:Spyhawk|Spyhawk]] ([[User talk: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]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:01, 3 April 2016 (UTC)
 +
 
 +
== Comparison table - solver: new test-case ==
 +
 
 +
{{AUR|ros-indigo-desktop}} has 201 AUR dependencies. Compared to {{AUR|plasma-meta-git}}, this shows another limitation of the AUR: RPC queries are done via GET requests, and querying many packages may result in an HTTP 414 error. {{AUR|pacaur}} ([https://github.com/rmarquis/pacaur/blob/9c5d3039dcda9028d39a4c85281f14afc27330c9/pacaur#L1131]), {{AUR|bauerbill}} ([http://xyne.archlinux.ca/projects/python3-aur/], 2016-02-01) and {{AUR|aurutils}} ([https://github.com/AladW/aurutils/blob/master/bin/aursearch#L63]) workaround this by splitting info queries.
 +
 
 +
That said, you could presumably avoid this issue altogether by not querying duplicates.
 +
 
 +
Results:
 +
 
 +
* {{AUR|aurutils}}: fails [https://github.com/AladW/aurutils/issues/111]
 +
* {{AUR|pkgbuilder}}: works
 +
* {{AUR|pacaur}}: works (build not tested)
 +
* {{AUR|bauerbill}}: not tested
 +
 
 +
I didn't bother with the others as they already failed on {{AUR|plasma-meta-git}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:57, 21 April 2016 (UTC)

Latest revision as of 10:57, 21 April 2016

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)

Comparison table - solver: new test-case

ros-indigo-desktopAUR has 201 AUR dependencies. Compared to plasma-meta-gitAUR, this shows another limitation of the AUR: RPC queries are done via GET requests, and querying many packages may result in an HTTP 414 error. pacaurAUR ([4]), bauerbillAUR ([5], 2016-02-01) and aurutilsAUR ([6]) workaround this by splitting info queries.

That said, you could presumably avoid this issue altogether by not querying duplicates.

Results:

I didn't bother with the others as they already failed on plasma-meta-gitAUR. -- Alad (talk) 10:57, 21 April 2016 (UTC)