Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
(Reliable solver: re)
(pikaur feature: "handle errors")
 
(483 intermediate revisions by 19 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)
+
== "Reference" implementation ==
}}
 
  
== Comparison table - build directory ==
+
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.
  
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.
+
I propose a minimal reference implementation with the following points:
  
The default values I've garnered so far, assuming TMPDIR is not set:
+
* 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.
 +
* Minimal language constructs in e.g. a scripting language like {{Pkg|dash}}.
 +
* Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.
  
* aurutils: $XDG_CACHE_HOME
+
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)
* 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)
+
: 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)
  
: 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)
+
::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.
 +
::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)
  
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (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.
::: 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.
+
::: 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)
::: 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).
+
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
  
== Multi-thread support ==
+
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
  
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 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
  
: 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.
+
Similar to the ''Diff view'' column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:32, 4 July 2018 (UTC)
: 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.
+
: 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)
:: 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)
+
: "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)
  
== <s>Unmaintained Aur Helpers</s> ==
+
:: 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)
  
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}}
+
::: 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)
  
: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)
+
:::: 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)
  
::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)
+
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (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.
+
== Native pacman revisited ==
:::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)
+
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.
  
:::::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 see some alternatives:
  
:::::: 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)
+
* <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>
 +
* Keep the column but remove Green/Grey colors, potentially renaming both the column and its entries.
  
::::::: 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)
+
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)
 +
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:21, 14 July 2018 (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 think the second approach is best since it offers more information/overview over the first. I propose the following changes:
 +
:*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)
  
::::::::: 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)
+
::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)
  
:::::::::: Feel free to make the change. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:13, 18 December 2017 (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)
  
::::::::::: 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
+
:::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)
  
== Reliable solver  ==
+
::::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.
 +
::::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)
  
https://aur.archlinux.org/packages/plasma-git-meta/ have some missing dependencies:
+
:::::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.
  discover-git
+
:::::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.
  oxygen-git
+
:::::[[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 17:11, 23 July 2018 (UTC)
  
Which other package can I use to test the criteria of being a reliable solver?
+
::::::I experimented a bit with [[User:Svito/Deleteme]], I like proposal with some changes:
[[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
+
::::::* 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)
  
: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)
+
:::::::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)
  
:: `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://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)
:: https://aur.archlinux.org/rpc/?v=5&type=search&arg=python2-catkin-pkg&by=name-desc
+
::::::::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)
:: https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=python2-catkin-pkg
 
  
:: For `plasma-desktop-git` i've got dependencies resolved (hopefully correctly):  
+
:::::::::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)
:: 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)
+
::::::::::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)
  
::::[https://paste.xinu.at/Kn7s/] [https://paste.xinu.at/w7Gud/] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 6 February 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)
 +
 
 +
::::::::::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)
 +
 
 +
== <s>pikaur feature: "handle errors"</s> ==
 +
[[User:Eschwartz]], you [https://wiki.archlinux.org/index.php?title=AUR_helpers&type=revision&diff=532377&oldid=532376 reverted my edit] and say pikaur skips errors, contrary the author saying it handles errors. do you have an example or a source code reference? normally i would be inclined to trust the tools author as he should know best, opensource coders do not brag too much about features as there is not much to gain - at least in my experience. i asked for a source code reference [https://github.com/actionless/pikaur/issues/240 here]. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 18:43, 3 August 2018 (UTC)
 +
 
 +
:It's linked in that very commit. If by "handle errors" you mean "skip pgp checks", then yes, it "handles" errors. But IMO the wiki is correct in referring to it as skipping them.
 +
:The error that it is skipping is the PGP error, not the failed build. Maybe it would be more accurate to say it "ignores" them rather than skipping them. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:50, 3 August 2018 (UTC)
 +
you mean [https://github.com/actionless/pikaur/commit/3688d828591d307c6864c3b5ad8c1f581396b865 this commit]? --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 14:24, 4 August 2018 (UTC)
 +
 
 +
::Yes, that's the commit linked in the table. As explained above, pikaur doesn't handle anything, it just passes {{ic|--skip-foo}} to makepkg. ({{ic|--skipinteg}} is a particularly novel one... :rolleyes:) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:27, 4 August 2018 (UTC)
 +
 
 +
:::i see, --skippgpcheck, --skipchecksums, --skipinteg, --ignorearch, and inventing a new text for a given feature, like skip integrity checks (checksum, pgp) is presented as "skip all validity checks".
 +
:::i'll [https://github.com/actionless/pikaur/issues/258 create a ticket] to suggest this confusionary gets fixed. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 14:42, 4 August 2018 (UTC)
 +
 
 +
::::There's nothing "confusionary" here. The only thing displayed here is that pikaur users behave like the pikaur author in trying to falsely advertise features. So unless you want to end up like the author, I suggest you stop doing that. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:11, 4 August 2018 (UTC)

Latest revision as of 15:11, 4 August 2018

"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 [1] 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: [2] -- 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 [3]). 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 [4], 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)

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

[5], in particular [6]

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)

Native pacman revisited

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

I see some alternatives:

  • 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.
  • 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. -- Alad (talk) 17:21, 14 July 2018 (UTC) -- 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:
  • 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 [7]. Alad (talk) 22:46, 21 July 2018 (UTC)
Works for me. I'm guessing the criteria will remain the same? Morganamilo (talk) 23:16, 21 July 2018 (UTC)
Yeah, unless someone brings new arguments to the table. I'll probably make some minor changes to fit the new wording. -- Alad (talk) 23:19, 21 July 2018 (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. Morganamilo (talk) 23:25, 21 July 2018 (UTC)
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.
Another point is whether to leave the column in place, or move it back to the end like the previous "Syntax" column. -- 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 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.
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 em 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
-- 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. -- Alad (talk) 10:22, 24 July 2018 (UTC)
[8] looks like a good approach since it immediately tells what's wrong instead of throwing fancy terms around -- 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 -- Alad (talk) 17:08, 24 July 2018 (UTC)
Yep: [9] It writes back the local pacman db with some mangled version. If you want crazy, look no further than yaourt. -- 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. -- Svito (talk) 09:33, 26 July 2018 (UTC)
Nice work. I ran out of tacos so here's a 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. -- 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? 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. -- 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. 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. -- Svito (talk) 18:14, 28 July 2018 (UTC)
There's a slight discrepancy though, in that - 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 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 pacman(8) to wrap that makes no sense either. -- Alad (talk) 14:22, 4 August 2018 (UTC)
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 /, 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? -- Eschwartz (talk) 03:17, 29 July 2018 (UTC)

pikaur feature: "handle errors"

User:Eschwartz, you reverted my edit and say pikaur skips errors, contrary the author saying it handles errors. do you have an example or a source code reference? normally i would be inclined to trust the tools author as he should know best, opensource coders do not brag too much about features as there is not much to gain - at least in my experience. i asked for a source code reference here. --Soloturn (talk) 18:43, 3 August 2018 (UTC)

It's linked in that very commit. If by "handle errors" you mean "skip pgp checks", then yes, it "handles" errors. But IMO the wiki is correct in referring to it as skipping them.
The error that it is skipping is the PGP error, not the failed build. Maybe it would be more accurate to say it "ignores" them rather than skipping them. -- Eschwartz (talk) 18:50, 3 August 2018 (UTC)

you mean this commit? --Soloturn (talk) 14:24, 4 August 2018 (UTC)

Yes, that's the commit linked in the table. As explained above, pikaur doesn't handle anything, it just passes --skip-foo to makepkg. (--skipinteg is a particularly novel one... :rolleyes:) -- Alad (talk) 14:27, 4 August 2018 (UTC)
i see, --skippgpcheck, --skipchecksums, --skipinteg, --ignorearch, and inventing a new text for a given feature, like skip integrity checks (checksum, pgp) is presented as "skip all validity checks".
i'll create a ticket to suggest this confusionary gets fixed. --Soloturn (talk) 14:42, 4 August 2018 (UTC)
There's nothing "confusionary" here. The only thing displayed here is that pikaur users behave like the pikaur author in trying to falsely advertise features. So unless you want to end up like the author, I suggest you stop doing that. -- Alad (talk) 15:11, 4 August 2018 (UTC)