"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  -- Alad (talk) 15:29, 16 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 isAUR which provides AUR and AUR. 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.
In line with the two topics above, we should add something on dependency resolution, cf.AUR. This package has 71 AUR dependencies, as well as discrepancies in the makedepends (such as vs. AUR)
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)
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)
- 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)
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)