Talk:AUR helpers

From ArchWiki
Revision as of 18:23, 1 March 2016 by Alad (talk | contribs) (→‎AUR4 changes: rm closed)
Jump to navigation Jump to search
Note: Moderation — If your AUR helper does partial upgrades without explicit user intervention (i.e, specifying -Sy on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- Alad (talk) 09:37, 20 September 2015 (UTC)

Pacman-like Syntax

"The colors in the "pacman syntax" column are questionable, as depending on perspective."

I strongly agree with this statement. The red color in the comparison table is used to underline missing capabilities, and a syntax similar to pacman can be either a strong or weak point, depending on the user point of view. Also, some helper (ie, pacaur) provide both set of commands. I'd suggest to use a neutral (white color) column that give example of an usual command (for example, the command to install a single package). Spyhawk (talk) 15:08, 16 February 2016 (UTC)

I'm not sure if example commands fit the scope of the table, but I've removed colors with [1] -- Alad (talk) 15:29, 16 February 2016 (UTC)
We have "Pacman-like" and "specific" now, users should be able to look up the specifics. Closing. -- Alad (talk) 20:23, 25 February 2016 (UTC)

Split package support

This is also part part of reliability, but requires more implementation work than simply using the RPC (or .SRCINFO). Obviously, this only concerns helpers that aim to provide automatic build.

A good PKGBUILD for testing this is python-novaclientAUR which provides python-novaclientAUR and python2-novaclientAUR. These packages have multiple split packages dependencies themselves.

In particular, split package support requires attention to:

  • the build order, as well as ensuring that split subpackages aren't built more than a single time;
  • the installation succeeds, with only the needed subpackages being installed;
  • the upgrades that should work without issues.

At the moment, bauerbill and pacaur have split package support, pkgbuilder correctly builds but fails on installing only the required split subpackages, and all the other helpers fail in some way or another.

I'm wondering if a separate column might be necessary here, or if it could be somehow merged with the "reliability" column discussed above. --Spyhawk (talk) 15:36, 16 February 2016 (UTC)

Dependency resolution

In line with the two topics above, we should add something on dependency resolution, cf. plasma-desktop-gitAUR. This package has 71 AUR dependencies, as well as discrepancies in the makedepends (such as extra-cmake-modules vs. extra-cmake-modules-gitAUR)

Most AUR helpers are either slow at this (Aura is the record holder, with ~80s on my machine), or get the order completely wrong (yaourt, wrapaur) resulting in package conflicts, or packages built against different dependency versions. -- Alad (talk) 15:48, 16 February 2016 (UTC)

I feel it will be difficult to find a way to describe reliability without overloading the comparison table with lot of extra columns, which might be an issue for low resolution screens. Maybe we should test different user cases and give a single reliability appreciation, such as "Bad, Medium, Good"? --Spyhawk (talk) 17:04, 16 February 2016 (UTC)
The approach we're going for in the table below seems to work out well, also failure in complex use-cases typically hints at a deeper problem, so I think a single Yes/No is the way to go. -- Alad (talk) 16:14, 18 February 2016 (UTC)
Yes, fully agree! --Spyhawk (talk) 16:51, 18 February 2016 (UTC)

Expanded table draft proposal

Here is a first draft of an expanded table proposal. Columns were added, and reordered. Security and technical aspects are displayed first, and subjective user preferences last. Some header cells were shortened, but the table might be too long, although better than I initially expected. --Spyhawk (talk) 23:08, 17 February 2016 (UTC)

I'm unsure on the "Reliable" in the column headers, as we have the red/yellow/green colors to convey the meaning, but it looks very nice otherwise. +1 -- Alad (talk) 12:27, 18 February 2016 (UTC)
Added some entries (preliminary, more links should be added). Maybe we should modify the descriptions to better distinguish between "source" and "parse" the PKGBUILD? -- Alad (talk) 13:54, 18 February 2016 (UTC)
Thanks Alad. I initially thought about only using "Parser" and "Solver" in the headers but "Solver: Yes/No" sounds definitely strange. Yes, we probably should think about enhancing description here. The "Secure" column is actually very related to the "Reliable parser" column, as a reliable parser using .SRCINFO/RPC is by definition secure. Maybe there is a way to merge these two column, but I haven't found a proper way to do it. Any suggestion welcome here. --Spyhawk (talk) 14:52, 18 February 2016 (UTC)
Ah, the above isn't true. See PKGBUILDer which uses the RPC but doesn't allow viewing of PKGBUILDs by default. We need a separate "Secure" column. --Spyhawk (talk) 17:12, 18 February 2016 (UTC)
Added a link to w:Parsing#Parser, and moved the table with [2] -- Alad (talk) 20:55, 18 February 2016 (UTC)

Blue colors for multilingual/shell completion

Shell completion and language support are nice to have, but I'm unsure that lack of suck features compares well to lack of basic functionality described in the other columns (Secure e.a). How about keeping the "No" entries, but making them blue, like for the N/A ones? "Yes" would remain green. -- Alad (talk) 19:54, 26 February 2016 (UTC)

True, this is hardly as important as other features. Same for multilingual support. I wouldn't mind not using any color at all. Spyhawk (talk) 21:16, 26 February 2016 (UTC)
Fair point on using no colors; I've tried using Blue, but it looked terrible and distracted attention from the N/A entries in other columns. I've also moved multilangual to the Specificity column, as it fits with other features like ABS support, while shell completion is more commonly expected (at least on English pages). Closing. -- Alad (talk) 23:21, 26 February 2016 (UTC)