Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
m (Multi-thread support: update)
(Outsourcing to GitHub: re x2)
 
(535 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)
  
:::: In hindsight, the only thing of relevance here is the use of the old {{ic|info}} interface over {{ic|multiinfo}} (with newer versions of the RPC, both are identical). For example, cower puts a drastic load on the AUR due to its use of one request per single package. I think the most effective way here is to migrate to helpers that implement the new interface and leave those that don't in the past. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:14, 22 February 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 {{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)
  
: may be one could come up with sort of "benchmark" (list of different commands related to querying or installing packages) and run them with different AUR helpers on one machine? that would be useful for both users (to see which one is faster now) and for developers (to improve the weak points of their apps). btw pikaur is using "Double Team" technique -- it's splitting itself into multiple threads to raise its evasiveness in face of big performance threat. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:26, 8 March 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". [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:11, 8 July 2018 (UTC)
  
:: Well, as pointed out above, speed isn't everything. e.g. aurutils has one of the fastest dependency solvers, but it throws away information like versioned deps or {{ic|provides}} in the process. Maybe this is of relevance: [https://github.com/polygamma/aurman/wiki/Description-of-the-aurman-dependency-solving#benchmarks---these-results-are-on-my-machine-your-mileage-may-vary] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:14, 8 March 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:25, 14 July 2018 (UTC)
  
== Reliable Updater ==
+
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (UTC)
  
Interested in feedback on possibly adding Reliable Updater as a category to Comparison table.
+
:::::: 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)
  
ie:
+
== Pacman wrappers Specificity ==
Does it handle accurate update status on VCS packages?
 
Does it handle accurate update status when developer fails to update .SCRINFO? https://wiki.archlinux.org/index.php/.SRCINFO
 
  
And any other unmentioned situations. [[User:Cody Learner|Cody Learner]] ([[User talk:Cody Learner|talk]]) 18:49, 22 February 2018 (UTC)
+
I wanted to introduce the ''manual AUR package selection'' specificity for pacman wrappers. For example '''yay''' and '''pakku''' only allow {{ic|-Syu}} where they update system packages and AUR packages at the same time. '''pikaur''' when doing {{ic|-Syu}} also updates system packages and AUR packages at the same time but prompt user for manual selection for AUR packages, because for example I want to update to the new version of X program but not the Y lib (AUR) that is used only by Z program (AUR) so until Z is not updated I don't want to update Y. And '''yaourt''' when doing {{ic|-Syu}} updates only system packages, {{ic|-Syu --aur}} is needed for updating AUR packages as well, and a manual selection for AUR packages is available. That's why I wanted to introduce the ''manual AUR package selection'' specificity. -- [[User:Noraj|Noraj]] ([[User talk:Noraj|talk]]) 11:16, 9 September 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 {{Bug|56602}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:02, 22 February 2018 (UTC)
+
:Why just not specify {{ic|--ignore ''ylib''}}? It is problem with ''zprogram'' if it does not use versioned deps and allows library update that breaks it. Helper should just fail to satisfy AUR deps in correct case, bail out and user should specify {{ic|--ignore}} manually explicitly IMO.
 +
:Additionally '''yay''' asks you what AUR packages to not upgrade that also provides solution to this [[w:XY problem|XY problem]].
 +
:All-in-all if you can no longer build some package from AUR correctly because of dependency update that package is broken and should be fixed or be removed instead. And helpers should ideally not provide workarounds for problems that broken package introduce.
 +
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:06, 9 September 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. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:19, 22 February 2018 (UTC)
+
::It's not really about broken programs. It could just as easily apply to some package that you're sure will compile fine, but you also remember takes 45 minutes to build, which you don't want to spend right now.
  
::: 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.
+
::Also I really don't consider using versioned deps, to be the correct case. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 14:45, 9 September 2018 (UTC)
::: 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. -- [[User:Alad|Alad]] ([[User talk: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? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 23:53, 22 February 2018 (UTC)
+
:::That's exactly my use case. Whether to allow it as a specificity or not? I'd probably say sure. But I also think there should be a cap on how many specificities an entry may have. I'd say max 4 or 5, otherwise the column may as well be called feature list. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 14:57, 9 September 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 23 February 2018 (UTC)
+
== New test cases for dependency resolution ==
  
== <s>"minimizes user interaction" is a misnomer</s> ==
+
ros-foo-desktop-meta have always been difficult to build, even more so with KDE4 libs moved to AUR (see arch-dev-public). Besides the sheer number of dependencies, they otherwise have little interesting properties either.
  
After that 'criteria' was removed it's leaving some gap in comparison.
+
I propose to instead use various cross-compilation packages as test cases, e.g. {{AUR|mingw-w64-zlib}} and {{AUR|powerpc-linux-gnu-gcc}}. These appear very efficient at exposing problems with complex dependency algorithms (see for example [https://github.com/Jguer/yay/issues/695] or ''aurman'''s issues with {{AUR|nsis}}) and don't take 2 years to build either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:34, 14 September 2018 (UTC)
I think we ned to come up with some better wording to describe those AUR helpers which allowing to review all the packages at once and next it's just building them without interrupting and asking more questions from user for each package.
 
I think it's quite crucial quality for application of such kind and for user it could be quite annoying installing each AUR helper and just trying to install two packages to see if it will ask all the questions right at once or before each package build. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:28, 22 February 2018 (UTC)
 
  
: Sorry, i've just noticed what you also added asterisk to Secure field to address that problem. But what do you think about moving it into separate column? Because i don't think it's so much about reviewing PKGBUILDs but also about other kinds of questions, like installing dependencies or package conflicts. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 20:32, 22 February 2018 (UTC)
+
:We could also add some simpler cases, like {{AUR|fortune-mod-all-en}}, and add details similar to the ''Split packages'' description. That way, all existing entries with "Yes" in ''Reliable solver'' would at minimum have "Partial". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:01, 14 September 2018 (UTC)
  
:: About the other kind, any helper that supports makepkg's --noconfirm can install dependencies without query. I find it questionable to make "predicting conflicts for currently installed packages" or somesuch a core feature (which a separate column implies), since the issue might not present itself in the first place e.g. through a local repo or containers. Not to mention the original point, that you can still get up to 200+ prompts with helpers implementing this feature.
+
:I believe the mingw stuff has a bunch of circular dependencies and a bootstrapping process. Do you think AUR helper's should be expected to handle this? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 15:25, 14 September 2018 (UTC)
:: That said, the asterisk was just something I've added quickly. A compromise may be a sensibly named column that isn't colored, akin to the shell completion column. ("linear", "batch" perhaps, compare "linear vs tsort" in [https://wiki.archlinux.org/index.php?title=Talk:AUR_helpers&oldid=474640]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:23, 22 February 2018 (UTC)
 
  
::: I suggest to simply use "batch inspection" in the specificity column instead of creating a new column. The main purpose of table imho is to be a quick reference of the status of the main steps of the process, rather than being an extensive description of each specific features. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 16:37, 23 February 2018 (UTC)
+
:: No, I don't think so. There will always be cases that can only be dealt reasonably manually, simply because the involved complexity in implementation isn't worth it. See also related sicussion [[Talk:AUR_helpers#.22Reference.22_implementation]] above, where a set of fixed reference packages would be better than live packages. No idea how to dealt with than without a local AUR instance though. -[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 10:42, 15 September 2018 (UTC)
  
:::: Sounds good to me. I'll edit it accordingly unless there's more feedback to offer. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:15, 23 February 2018 (UTC)
+
::: The mingw packages haven't had cycles in (global) depends for a while. As such, {{ic|makepkg -r}} works fine for these packages without manual intervention or "bootstrapping". If helpers fail, it may be because of handling split depends contrary to PKGBUILD(5), or other flaws in their dependency algorithms. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 18 September 2018 (UTC)
  
::::: Done: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=511910&oldid=511814]. Suggestions on a precise name for aurman/pacaur's "deep search" feature for the specifity column? (e.g. pkgbuilder, trizen, aurutils have none of that) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 24 February 2018 (UTC)
+
== Outsourcing to GitHub ==
  
:::::: I am not good at coming up with precise names, but let me explain the intention behind the feature. Maybe that will help one of you coming up with a precise name. Most dep solving algorithms look at the unfulfilled dependencies only, but that can lead to not finding a valid solution on rare occasions. Example: You have package A installed on your system and A needs "B". "B" is being provided by a package called B directly, but you fulfilled that dep with another package called B_1. Now you want to update package A to a newer version and also install package C. C conflicts with B_1, and B_1 only. If the dep solving algo just looks at unfulfilled deps, it will ignore B, because B_1 is installed. But that conflicts with C, so no solution is being found. "Deep search" of aurman ignores everything installed and is thus able to find the solution of removing B_1, installing B and C and upgrading A [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 16:00, 24 February 2018 (UTC)
+
:To put an end to these unannounced edits taking excessive wiki admin time, I will be moving the comparison table to github [https://github.com/aurdc/helpers], and the article remainders to the (more closely followed) [[AUR]] article. Besides the pull request/review model, there are some other benefits to this approach, such as keeping AUR helper discussions in one place. These discussions have often taken place on github before, often in unrelated/offtopic issues for helper projects.
 +
:I've invited most of the regular contributors to the [[AUR helpers]] article and related discussion to the new "organization". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:05, 1 October 2018 (UTC)
  
::::::: I had written "dependency solving independent from the installed packages (optional)" for the "deep_search" feature in the specificity column of aurman, but that has been [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=next&oldid=512105 deleted]. Tbh I cannot really follow the argumentation behind the removal. Why should the circumstance that it is almost never needed be a criterium to not put it in that column? It's nevertheless a feature which is unique by that helper, which makes it a specificity. Besides that: If one wants to install some package with another AUR helper and finding a solution fails, that "deep_search" feature could exactly be what he needs. And stating that the column is not a full features list, how does that matter for the removal of the entry? It is just one of many features... If this is the wrong place for a discussion about that removal - sorry, where do I have to put it? [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 07:46, 27 February 2018 (UTC)
+
::I disagree with the outsourcing to GitHub. Can't the page be locked to administrators? The fact that MediaWiki's contribution model is limited affects all pages, not just this one, and just because discussions take place somewhere doesn't mean documentation should move there too. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:28, 1 October 2018 (UTC)
  
:::::::: This is the correct place. I think the main objection is that it's a rather long description of a single feature - as you may notice in the column, specifities are usually not longer than a few words. I've went with Spyhawk's proposal for now to use "batched interaction", [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512180&oldid=512148] but we can leave this discussion open for further proposals. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:09, 27 February 2018 (UTC)
+
:::I think existing editors do a good job of maintaining this article in good shape and reverting bad edits. I made edit in question at late night and it was reverted in the morning and it is not like I started edit war or disagree with revert reason. I think revert was good and started a discussion that already resulted in later improvement to the article. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:44, 1 October 2018 (UTC)
  
:::::::: What does "bootstrapping packages" mean? [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512764&oldid=512724] Also what helpers do support versioned dependencies, and is it really worth including as a specifity due to the rarity of their occurence? Compare to the note on architecture specific fields which could extend instead, adding {{Bug|54906}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:08, 5 March 2018 (UTC)
+
::::Yeah but Alad's point is that it takes excessive wiki admin time. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:46, 1 October 2018 (UTC)
  
::::::::: Well, I googled quite a bit do come up with a term that describes what I mean, maybe the name isn't good. Example is the mingw-w64-gcc package - installing packages for building and then removing them again is meant. Regarding the versioned deps: Two examples I know for sure: trizen and pikaur. Wanting to install "aurman-git>1.0" yields in both cases: Not found. [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 15:20, 5 March 2018 (UTC)
+
:::::I can do my part and stop authoring edits on this and other articles and go back to only patrolling and this problem would mostly disappear. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:15, 1 October 2018 (UTC)
  
:::::::::: Well anything supporting {{ic|makepkg --rmdeps}} can install packages and remove them again. E.g. aurutils can do that to a further extent since it uses a local repo, but it can't build mingw-w64-gcc as it has a too rudimentary dependency solving algorithm.
+
::: +1 for locking. If Alad is afraid of his personal time (since he's the main admin working on that article afaik), moving it to GH will only take more of his free time there :) --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 20:20, 1 October 2018 (UTC)
:::::::::: I'll add a note then with the above bug report and {{ic|aurman}}, {{ic|pacaur}}. I'll leave it to the authors of other helpers to add to the note if their helper supports versioned dependencies. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:38, 5 March 2018 (UTC)
 
  
::::::::::: I've just used "deep search" and added a link to your awesome post on the aurman dependency algorithm. [https://wiki.archlinux.org/index.php?title=AUR_helpers&type=revision&diff=512786&oldid=512784] Is this agreeable enough to close this discussion? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 5 March 2018 (UTC)
+
:::: Locking to administrators is something I have tried and which was not fruitful in the long term. It put all editing responsibility on my behalf and was unfair to users who contributed fairly to the article. The note on not editing is equally useless when even official wiki maintainers disregard it.
 +
:::: Now as it turns out, while github has a useful permission model, duplicating mediawiki in markdown is horrifying. GitHub wikis can't be used with pull requests either. I will investigate if additional user groups can be added to the wiki, something I've wanted to for a while. If that doesn't work out, it's perhaps time to leave the [[AUR helper]] chapter behind for good. It's caused enough trouble and the majority of the target audience does not understand the content anyway. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:18, 5 October 2018 (UTC)
  
:::::::::::: Seems fine to me :) [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 20:56, 5 March 2018 (UTC)
+
::::: I understand your worries, since this topic is a black hole that sucks an enormous amount of time and energy. I do have doubt about moving it externally since this wouldn't solve any of these problems, especially if you take care of it by yourself. I would suggest to revert the article to its initial form: a simple alphabetical list of helpers available without any comparison table. Don't externalise the info, just remove it - and put a restriction on creating such a comparison in the official wiki. Users should make their mind by themselves, and if some other people want to create a fair (or biased) comparison page somewhere else, so be it. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 12:24, 5 October 2018 (UTC)
  
:::::: What about "batched interaction"? [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 17:18, 24 February 2018 (UTC)
+
::::::Comparison tables help users make up their minds, an alphabetical list would be useless. I doubt a fair comparison page would be created elsewhere. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 13:05, 5 October 2018 (UTC)
  
== <s>Separate table for unmaintained/old helpers</s> ==
+
:::::::Except that it has proven over time that the table doesn't help in making an informed decision - as you might expect with any other article or table in the wiki - but rather lends excessive bias to whatever entry ''happens'' to have the greatest amount of ''green colored cells'', resp. is placed at the top of the table.
 +
:::::::Regarding an alphabetical list, I've considered properly using the {{ic|aur}} keyword instead. It requires no maintenance on our behalf and should always be updated. There are a few false positives, because no exact match can be done on "aur", e.g. "thesaurus" is included. [https://aur.archlinux.org/packages/?O=0&SeB=k&K=aur&outdated=&SB=n&SO=a&PP=50&do_Search=Go] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:06, 8 October 2018 (UTC)
  
Right now the table is filled with entries that are no longer relevant apart for historical reasons (pacaur is one example that reached prominence, but there are many others like packer, aurget, burgaur, etc.). Since they technically still "work", I wouldn't remove them from this article, but either:
+
::::::::If you just want to make AUR helpers searchable in the AUR itself, you can tag them with "aur-helper" instead. [https://aur.archlinux.org/packages/?SeB=k&K=aur-helper] -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:33, 8 October 2018 (UTC)
  
* keep them in the same table with grey-colored columns (compare [[de:AUR Hilfsprogramme]])
+
:::::::::Sounds good.  -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:30, 10 October 2018 (UTC)
* put them in a separate table
 
* put them in a separate table with grey-colored columns
 
* put them in a list, bulleted or using [[Template:App]] (compare [[Arch-based_distributions#Inactive]])
 
  
Thoughts? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:00, 25 February 2018 (UTC)
+
::::::::We try the best we can to have factual advice but in the end it is responsibility of individuals to pick their poison. I would prefer we work further on following:
 +
::::::::* Some people still don't take responsibility for their system while installing Arch
 +
::::::::** We should explain better what supported or unsupported means and how free software works in terms of support
 +
::::::::* Some people suggest use of "Pacman wrappers" when referring to AUR helpers in general
 +
::::::::** We should explain better why you should prefer using "Download and build helpers" over "Pacman wrappers"
 +
::::::::I think explaining what we failed to explain is more positive way to go with this article and ArchWiki in general.
 +
::::::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 18:43, 8 October 2018 (UTC)
  
:I think any of those options are good (along with a warning or note). Are any of the older packages simply "feature complete" (no updates since the author considers the program done)?
+
:::::::::I have some doubts on how well this fits in the ArchWiki scope, but a description of "unsupported" (for AUR) and "unsupported^2" (for AUR helpers) can be left in [[AUR]]. It doesn't require a dedicated article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:30, 10 October 2018 (UTC)
:{{Unsigned|01:22, 26 February 2018‎ |Rdeckard}}
 
 
 
: I like the solution with the grey-colored columns in the same table the most. Everything stays in place, but it's visually easy to see which projects are still "relevant" [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 09:12, 26 February 2018 (UTC)
 
 
 
:Dealing with the table alone doesn't make much sense, what about the lists above it? Would they be split or greyed out as well? How would you call the split sections - "unmaintained" vs "supported" or something like that? I know that you won't like the sound of "supported" here, but I can't think of a better alternative right now. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:57, 26 February 2018 (UTC)
 
:: Would a column with the last update date or last release date give an idea whether the helper is actively maintained or not? -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 22:41, 1 March 2018 (UTC)
 
 
 
:::A problem with that is that it would get frequently outdated for the active projects. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:52, 2 March 2018 (UTC)
 
::::True and you think showing only the year of the last release date would not be precise enough? -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 08:04, 2 March 2018 (UTC)
 
 
 
:::::In my case, aurutils is unlikely to get another release until 2019-2020 so it would appear quite inactive even though it is anything but... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:50, 2 March 2018 (UTC)
 
 
 
::::: You'd need more than a date to decide if a project is actively maintained anyway. Some project are well established with very few bugs, while other got only some recent but very minor code update while still ignoring the most blatant issues for many years. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:25, 2 March 2018 (UTC)
 
 
 
::::: Then in my opinion splitting the table in 2 sections, maintained/inactive based on your expert judgement of the helpers (a mix of last release date and future expected dev) would be good. Keeping, for the moment at least, the same format eases comparison between current and legacy helpers. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 16:23, 2 March 2018 (UTC)
 
 
 
::::: See [[Synchronization_and_backup_programs]], why not using a maintained column like there. -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 17:08, 4 March 2018 (UTC)
 
 
 
:::::: So I guess [[Template:Yes]] for active development, [[Template:Y]] for inactive but with an "available" maintainer, and [[Template:No]] for unmaintained? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:22, 4 March 2018 (UTC)
 
 
 
::::::: Fine with me -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 18:13, 4 March 2018 (UTC)
 
 
 
:::::::: "Expert judgement" is vague and subjective. You probably want to define some explicit criteria (even if they are skewed) so helpers can be judged against the same baseline. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 20:15, 4 March 2018 (UTC)
 
 
 
::::::::: The red column should be easy, i.e. "Projects that were abandoned by the author, in favor of a different project or otherwise" with some explanative link for each entry. Yellow could be when long-standing issues are not addressed. That leaves some edge cases, like when a project has frequent commits but issues are not addressed, but in general you'd give other entries a Yes. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:02, 4 March 2018 (UTC)
 
 
 
:::::::::: Here's an attempt: A project is "active" if 1/ it isn't officially discontinued/unmaintained, 2/ has a main regular contributor (generally the main author), with some commits of his own at least the past 6 months (in contrast to punctual contributors that work on unimportant issues), 3/ important issues of security and clean build are being actively worked on (commit being pushed or interest in doing so displayed in the past 6 months). That should cover the edge-cases. The proposed duration can be adjusted, ie. ~3 months could be more adequate. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 08:43, 5 March 2018 (UTC)
 
 
 
::::::::::: Sounds ok to me. I'd probably stick to 6 months or more, otherwise projects like Aura which are more reliable since last year would be immediately classified as "inactive". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:13, 5 March 2018 (UTC)
 
 
 
:::::::::::: Proposal: [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512792&oldid=512790] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:26, 5 March 2018 (UTC)
 
:::::::::::: Concerning "general activity" and Rdeckard's comment on "feature complete" helpers, perhaps this could include issue tracking or author reponse (assuming the other criteria are fulfilled). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:29, 5 March 2018 (UTC)
 
 
 
::::::::::::: I'd put the maintenance column in the front to make helper selection more straightforward, but otherwise LGTM. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 17:05, 5 March 2018 (UTC)
 
 
 
:::::::::::::: Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=512818&oldid=512800] cheers -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 5 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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:45, 5 March 2018 (UTC)
 
 
 
: Agree, but is this possible to sort by default? See [https://www.mediawiki.org/wiki/Help:Sorting#Sorting_rows_of_a_table 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"). -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 00:35, 6 March 2018 (UTC)
 
 
 
== "AUR repo diff" ==
 
 
 
[https://wiki.archlinux.org/index.php?title=AUR_helpers&curid=4748&diff=512978&oldid=512964] no idea what that's supposed to mean. If it's git diffs, half of the table supports those. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:59, 8 March 2018 (UTC)
 
 
 
: yup, that means exactly that. i wasn't sure if it worth mentioning or not [[User:Actionless|Actionless]] ([[User talk: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:58, 8 March 2018 (UTC)
 
 
 
::: good idea [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 12:59, 8 March 2018 (UTC)
 

Latest revision as of 14:30, 10 October 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)
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)

Pacman wrappers Specificity

I wanted to introduce the manual AUR package selection specificity for pacman wrappers. For example yay and pakku only allow -Syu where they update system packages and AUR packages at the same time. pikaur when doing -Syu also updates system packages and AUR packages at the same time but prompt user for manual selection for AUR packages, because for example I want to update to the new version of X program but not the Y lib (AUR) that is used only by Z program (AUR) so until Z is not updated I don't want to update Y. And yaourt when doing -Syu updates only system packages, -Syu --aur is needed for updating AUR packages as well, and a manual selection for AUR packages is available. That's why I wanted to introduce the manual AUR package selection specificity. -- Noraj (talk) 11:16, 9 September 2018 (UTC)

Why just not specify --ignore ylib? It is problem with zprogram if it does not use versioned deps and allows library update that breaks it. Helper should just fail to satisfy AUR deps in correct case, bail out and user should specify --ignore manually explicitly IMO.
Additionally yay asks you what AUR packages to not upgrade that also provides solution to this XY problem.
All-in-all if you can no longer build some package from AUR correctly because of dependency update that package is broken and should be fixed or be removed instead. And helpers should ideally not provide workarounds for problems that broken package introduce.
-- Svito (talk) 13:06, 9 September 2018 (UTC)
It's not really about broken programs. It could just as easily apply to some package that you're sure will compile fine, but you also remember takes 45 minutes to build, which you don't want to spend right now.
Also I really don't consider using versioned deps, to be the correct case. -- Eschwartz (talk) 14:45, 9 September 2018 (UTC)
That's exactly my use case. Whether to allow it as a specificity or not? I'd probably say sure. But I also think there should be a cap on how many specificities an entry may have. I'd say max 4 or 5, otherwise the column may as well be called feature list. Morganamilo (talk) 14:57, 9 September 2018 (UTC)

New test cases for dependency resolution

ros-foo-desktop-meta have always been difficult to build, even more so with KDE4 libs moved to AUR (see arch-dev-public). Besides the sheer number of dependencies, they otherwise have little interesting properties either.

I propose to instead use various cross-compilation packages as test cases, e.g. mingw-w64-zlibAUR and powerpc-linux-gnu-gccAUR. These appear very efficient at exposing problems with complex dependency algorithms (see for example [7] or aurman's issues with nsisAUR) and don't take 2 years to build either. -- Alad (talk) 11:34, 14 September 2018 (UTC)

We could also add some simpler cases, like fortune-mod-all-enAUR, and add details similar to the Split packages description. That way, all existing entries with "Yes" in Reliable solver would at minimum have "Partial". -- Alad (talk) 12:01, 14 September 2018 (UTC)
I believe the mingw stuff has a bunch of circular dependencies and a bootstrapping process. Do you think AUR helper's should be expected to handle this? Morganamilo (talk) 15:25, 14 September 2018 (UTC)
No, I don't think so. There will always be cases that can only be dealt reasonably manually, simply because the involved complexity in implementation isn't worth it. See also related sicussion Talk:AUR_helpers#.22Reference.22_implementation above, where a set of fixed reference packages would be better than live packages. No idea how to dealt with than without a local AUR instance though. -Spyhawk (talk) 10:42, 15 September 2018 (UTC)
The mingw packages haven't had cycles in (global) depends for a while. As such, makepkg -r works fine for these packages without manual intervention or "bootstrapping". If helpers fail, it may be because of handling split depends contrary to PKGBUILD(5), or other flaws in their dependency algorithms. -- Alad (talk) 10:05, 18 September 2018 (UTC)

Outsourcing to GitHub

To put an end to these unannounced edits taking excessive wiki admin time, I will be moving the comparison table to github [8], and the article remainders to the (more closely followed) AUR article. Besides the pull request/review model, there are some other benefits to this approach, such as keeping AUR helper discussions in one place. These discussions have often taken place on github before, often in unrelated/offtopic issues for helper projects.
I've invited most of the regular contributors to the AUR helpers article and related discussion to the new "organization". -- Alad (talk) 12:05, 1 October 2018 (UTC)
I disagree with the outsourcing to GitHub. Can't the page be locked to administrators? The fact that MediaWiki's contribution model is limited affects all pages, not just this one, and just because discussions take place somewhere doesn't mean documentation should move there too. --Larivact (talk) 16:28, 1 October 2018 (UTC)
I think existing editors do a good job of maintaining this article in good shape and reverting bad edits. I made edit in question at late night and it was reverted in the morning and it is not like I started edit war or disagree with revert reason. I think revert was good and started a discussion that already resulted in later improvement to the article. -- Svito (talk) 16:44, 1 October 2018 (UTC)
Yeah but Alad's point is that it takes excessive wiki admin time. --Larivact (talk) 16:46, 1 October 2018 (UTC)
I can do my part and stop authoring edits on this and other articles and go back to only patrolling and this problem would mostly disappear. -- Svito (talk) 17:15, 1 October 2018 (UTC)
+1 for locking. If Alad is afraid of his personal time (since he's the main admin working on that article afaik), moving it to GH will only take more of his free time there :) --Spyhawk (talk) 20:20, 1 October 2018 (UTC)
Locking to administrators is something I have tried and which was not fruitful in the long term. It put all editing responsibility on my behalf and was unfair to users who contributed fairly to the article. The note on not editing is equally useless when even official wiki maintainers disregard it.
Now as it turns out, while github has a useful permission model, duplicating mediawiki in markdown is horrifying. GitHub wikis can't be used with pull requests either. I will investigate if additional user groups can be added to the wiki, something I've wanted to for a while. If that doesn't work out, it's perhaps time to leave the AUR helper chapter behind for good. It's caused enough trouble and the majority of the target audience does not understand the content anyway. -- Alad (talk) 08:18, 5 October 2018 (UTC)
I understand your worries, since this topic is a black hole that sucks an enormous amount of time and energy. I do have doubt about moving it externally since this wouldn't solve any of these problems, especially if you take care of it by yourself. I would suggest to revert the article to its initial form: a simple alphabetical list of helpers available without any comparison table. Don't externalise the info, just remove it - and put a restriction on creating such a comparison in the official wiki. Users should make their mind by themselves, and if some other people want to create a fair (or biased) comparison page somewhere else, so be it. --Spyhawk (talk) 12:24, 5 October 2018 (UTC)
Comparison tables help users make up their minds, an alphabetical list would be useless. I doubt a fair comparison page would be created elsewhere. --Larivact (talk) 13:05, 5 October 2018 (UTC)
Except that it has proven over time that the table doesn't help in making an informed decision - as you might expect with any other article or table in the wiki - but rather lends excessive bias to whatever entry happens to have the greatest amount of green colored cells, resp. is placed at the top of the table.
Regarding an alphabetical list, I've considered properly using the aur keyword instead. It requires no maintenance on our behalf and should always be updated. There are a few false positives, because no exact match can be done on "aur", e.g. "thesaurus" is included. [9] -- Alad (talk) 11:06, 8 October 2018 (UTC)
If you just want to make AUR helpers searchable in the AUR itself, you can tag them with "aur-helper" instead. [10] -- Eschwartz (talk) 15:33, 8 October 2018 (UTC)
Sounds good. -- Alad (talk) 14:30, 10 October 2018 (UTC)
We try the best we can to have factual advice but in the end it is responsibility of individuals to pick their poison. I would prefer we work further on following:
  • Some people still don't take responsibility for their system while installing Arch
    • We should explain better what supported or unsupported means and how free software works in terms of support
  • Some people suggest use of "Pacman wrappers" when referring to AUR helpers in general
    • We should explain better why you should prefer using "Download and build helpers" over "Pacman wrappers"
I think explaining what we failed to explain is more positive way to go with this article and ArchWiki in general.
-- Svito (talk) 18:43, 8 October 2018 (UTC)
I have some doubts on how well this fits in the ArchWiki scope, but a description of "unsupported" (for AUR) and "unsupported^2" (for AUR helpers) can be left in AUR. It doesn't require a dedicated article. -- Alad (talk) 14:30, 10 October 2018 (UTC)