Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
m (`Reliable solver` discussion: typo)
(Yaourt is back at AUR: new section)
 
(736 intermediate revisions by 28 users not shown)
Line 1: Line 1:
{{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)
+
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
}}
 
  
== Comparison table - build directory ==
+
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
  
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 new criteria would be as follows:
 +
* 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
  
The default values I've garnered so far, assuming TMPDIR is not set:
+
Similar to the ''Diff view'' column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:32, 4 July 2018 (UTC)
  
* aurutils: $XDG_CACHE_HOME
+
: 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)
* 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:Alad|Alad]] ([[User talk:Alad|talk]]) 18:16, 1 April 2016 (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.
 +
: 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)
  
: 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)
+
:: 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.
 +
:: 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)
  
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (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)
::: 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. -- [[User:Alad|Alad]] ([[User talk: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. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:35, 4 April 2016 (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)
  
== Multi-thread support ==
+
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (UTC)
  
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)
+
:::::: 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)
  
: 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.
+
== <s>pacaur seems discontinued/unmaintained</s> ==
: 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.
+
(see https://github.com/rmarquis/pacaur)
:: 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)
+
pacaur is not listed as discontinued/unmaintained although github and forum (https://bbs.archlinux.org/viewtopic.php?pid=1755144#p1755144) say that
  
== <s>Unmaintained Aur Helpers</s> ==
+
{{Unsigned|07:36, 21 March 2019 (UTC)|Vladmihaisima}}
  
It seems my edit to adding the info about Pacaur being unmaintained was reverted. Are we not allowed to mark aur helpers as unmaintained? What is the proper way to go about letting users know that things like Pacaur are now unmaintained upstream?[https://github.com/rmarquis/pacaur] {{unsigned|19:33, 18 December 2017‎|Ase1590}}
+
:It has been continued by E5ten. Check AUR package, it has new upstream URL. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 08:21, 21 March 2019 (UTC)
  
:Unmaintained helpers are not a big deal since helpers should only be used by people who can solve their own problems (as indicated by the warning at the top of the article). However, if you can demonstrate that a helper ''actually stops working'' in a general sense, with no community interest to fix it, you can remove them from the article. (and file a request on AUR as well) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:43, 18 December 2017 (UTC)
+
== Yaourt is back at AUR ==
  
::I would argue that an [unmaintained] tag would be helpful for quickly finding an AUR helper instead of having to futz around on github pages to see that it has not be updated in X amount of months/years and that it has been abandoned. I agree that if an aur helper ''actually'' broke due to some update, that it would be a candidate for removal from the AUR helper page. The whole point of wiki info is for at-glance quick info, otherwise, it'd be documentation and not a wiki. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 18:59, 18 December 2017 (UTC)
+
Mention to Yaourt was removed from this article in [[Special:Diff/569732]] because this software was removed from AUR ([https://lists.archlinux.org/pipermail/aur-requests/2019-March/030519.html Deletion request thread]). However it seems eschwartz brought it back in 27/03/2019. Maybe the removal should be undone? -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 04:34, 14 April 2019 (UTC)
 
 
:::That brings other issues. First, you'd have to make a reasonable definition of "unmaintained". Should it be an official statement from the maintainer where he distances himself from the project? Should it be some fixed interval between commits? Should it be how upstream cares for outstanding issues? If you include the last two criteria, 90% of the AUR helpers on this page classifies as "unmaintained" and the value of the tag is lost.
 
:::Second, the "unmaintained" information would have to be continually checked to keep the page factual, which for 23 helpers in [[AUR helpers#Build and search]] alone is hardly reasonable. Especially when you as the user already has a nice table at the bottom, which narrows down your choice to 3-4 projects (entries with all the green) already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:14, 18 December 2017 (UTC)
 
 
 
::::I think we can use your first definition of unmaintained as the formal definition for this page. The developer of Pacaur has made an official statement where he is distancing himself. As for the second point, the "continually checked" argument does not make sense for a wiki, as users are free to edit and update information whenever. All wiki pages can be subject to information rot, just look at some of the less common non-english pages in the arch wiki, which have in one instance in IRC displayed information about configuring arch prior to Systemd integration. Wikis stay up to date so long as other users contribute. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:29, 18 December 2017 (UTC)
 
 
 
:::::It still makes no sense to me as it punishes projects for maintainers declaring them as unmaintained. Other projects could make no such announcement and be left in a far worse state, yet as they would not be marked as "unmaintained", would be prioritized in their consideration. (which again, is not deserved) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:32, 18 December 2017 (UTC)
 
 
 
:::::: I suppose we could add a softer toned tag such as [project maintainer needed] that way this instead encourages people to pick it up upstream when reading. Formally abandoned packages are going to lose support over time anyway from social media like reddit and those subscribed to the project via things like github, and it can't be helped (especially if the package outright becomes broken/incompatible). [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:41, 18 December 2017 (UTC)
 
 
 
::::::: That's a notion I can support. I'm not sure on the best format to add such a tag to the page. It seems out of place in the "Specificity" column of the comparison table (since it's not a feature of the project); on the other hand, it's more in plain view there and e.g. aura already mentions an aspect not strictly feature-related (the need for ArchHaskell). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:51, 18 December 2017 (UTC)
 
 
 
:::::::: How about [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=503126&oldid=503125] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:57, 18 December 2017 (UTC)
 
 
 
::::::::: I like this, though it might look more pleasing if it were moved under the Build and Search heading at the end of the pacaur description, though that ''could'' just be my OCD just kicking in. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 20:06, 18 December 2017 (UTC)
 
 
 
:::::::::: Feel free to make the change. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:13, 18 December 2017 (UTC)
 
 
 
::::::::::: After thinking about it, I think yours is best. Most attention will be focused on the table as you said earlier, so if the aim is to attract new contributers to a project then it makes most sense for it to be in the highest visibility area, which in this case is the comparison table -- 21:19, 18 December 2017‎ Ase1590
 
 
 
== Reliable solver  ==
 
 
 
https://aur.archlinux.org/packages/plasma-git-meta/ have some missing dependencies:
 
  discover-git
 
  oxygen-git
 
 
 
Which other package can I use to test the criteria of being a reliable solver?
 
[[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
 
 
:Try plasma-desktop-git or ros-indigo-desktop. I tried testing it myself but couldn't since pkaur failed immediately with a python traceback. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 5 February 2018 (UTC)
 
 
 
:: `ros-indigo-desktop` failed because it depends on https://aur.archlinux.org/packages/ros-indigo-catkin/ which depends on `python2-catkin-pkg` (which provided by https://aur.archlinux.org/packages/python2-catkin_pkg/). However AUR RPC seems to be not supports search by Provides field:
 
:: https://aur.archlinux.org/rpc/?v=5&type=search&arg=python2-catkin-pkg&by=name-desc
 
:: https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=python2-catkin-pkg
 
 
 
:: For `plasma-desktop-git` i've got dependencies resolved (hopefully correctly):
 
:: https://imgur.com/a/9dA5S however it's gonna build for month or so on my hardware. Mb there is some way to reproduce it with some simpler example? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
 
 
::: Also could you please upload the traceback somewhere? It's probably unrelated to resolving but still will be useful for me. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:32, 5 February 2018 (UTC)
 
 
 
::::[https://paste.xinu.at/Kn7s/] [https://paste.xinu.at/w7Gud/] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 6 February 2018 (UTC)
 
 
 
::::: thanks! and what is the output of `file /var/lib/pacman/sync/custom.db`? i have idea how to fix that but first i am trying to understand if .db file is always gzip or its format could vary
 
 
 
::::: also dependencies list for plasma got computed the same (in pikaur some of deps were duplicated but i've fixed that already) [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 21:14, 6 February 2018 (UTC)
 
 
 
::::::The database files can also be ''xz'' or any other format that ''bsdtar'' supports. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:39, 6 February 2018 (UTC)
 
 
 
::::::: Thanks, i've updated it to use `bsdtar` instead of `gzip`, and also added some error handling to that stage. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 23:57, 6 February 2018 (UTC)
 

Latest revision as of 04:34, 14 April 2019

Expand Secure criteria to include other (non-PKGBUILD) bundled files

[1], in particular [2]

The new criteria would be as follows:

  • 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. -- Alad (talk) 16:32, 4 July 2018 (UTC)

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 Polygamma (talk) 17:07, 4 July 2018 (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.
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. 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 .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.
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. -- 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". Morganamilo (talk) 20:11, 8 July 2018 (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. -- Alad (talk) 17:25, 14 July 2018 (UTC)
I guess "File view" could work. -- Alad (talk) 17:44, 14 July 2018 (UTC)
The column name was updated to "File review". Are there remaining helpers that only display the PKGBUILD? (trizenAUR springs to mind) -- Alad (talk) 15:30, 23 August 2018 (UTC)

pacaur seems discontinued/unmaintained

(see https://github.com/rmarquis/pacaur)

pacaur is not listed as discontinued/unmaintained although github and forum (https://bbs.archlinux.org/viewtopic.php?pid=1755144#p1755144) say that

—This unsigned comment is by Vladmihaisima (talk) 07:36, 21 March 2019 (UTC). Please sign your posts with ~~~~!

It has been continued by E5ten. Check AUR package, it has new upstream URL. -- Svito (talk) 08:21, 21 March 2019 (UTC)

Yaourt is back at AUR

Mention to Yaourt was removed from this article in Special:Diff/569732 because this software was removed from AUR (Deletion request thread). However it seems eschwartz brought it back in 27/03/2019. Maybe the removal should be undone? -- Josephgbr (talk) 04:34, 14 April 2019 (UTC)