Talk:AUR helpers

From ArchWiki
Revision as of 20:49, 9 January 2019 by Alad (talk | contribs) (Remove pacaur: rm closed)
Jump to navigation Jump to search

"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)
I will close this topic for the following reason: the current approach of finding correct test cases, and basing the reliability of AUR helpers on them, has in the end failed. Instead of looking at the relevant specifications (PKGBUILD(5), makepkg(1), pacman(8) and so on), most helpers only consider the small set of test packages, and then fail when there's some new package which is valid, but has unexpected behavior. (Some helpers even invent new (invalid) specifications in such a case...)
The approach of following the PKGBUILD specification to the letter has at least worked well for me - whenever I see some new package which fails to build with the big helpers, it has no issue at all with aurutils - even when aurutils has nearly no testing of note. -- Alad (talk) 20:47, 9 January 2019 (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)

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)
Closing, see [8]. -- Alad (talk) 20:48, 9 January 2019 (UTC)

Checkmarks instead of colors

I propose to use ✅ (U+2705) and ❎ (U+274E) instead of Template:Yes and Template:No. While uncommon in the wiki, the checkmarks are more subtle than fully colored cells, and might lead to a more thoughtful response when choosing helpers (compare the common "pick the all green row" responses we have now).

Example: [9] -- Alad (talk) 16:20, 30 November 2018 (UTC)

That check mark has different appearance depending on Emoji font. There is Template:Ya and Template:Na that use colored text-presentation symbols, but one would probably figure out that "pick the all green row" is similar to "pick the row with all checkmarks", especially since both ✅ (U+2705) and Template:Ya have green color. -- Svito (talk) 18:28, 30 November 2018 (UTC)
You could also use plain text "Yes" and "No" instead of the templates if you want to skip the colors. But due to the sorting criteria users probably tend to choose from the top... -- Lahwaacz (talk) 20:29, 30 November 2018 (UTC)
Draft User:Alad/AUR_helpers:
  • Removes sorting criteria, sort alphabetically instead;
  • Remove batch interaction 2 and 3 as column entries, add "resolve package conflicts" and "combined upgrade" to specificity instead;
  • Replace Template:Yes with Template:Ya and Template:No with Template:Na;
As an alternative to the checkmarks (better suited for screenreaders), see: [10]
  • Remove some redundant specificity entries to keep a maximum of 4 entries;
  • Remove Batch interaction 1;
For the last point, while it's a separate aspect of "file review", 80% of the helpers support it by now. I'd rather have the additional space from having one column less. -- Alad (talk) 19:06, 1 December 2018 (UTC)
In line with the added neutrality from removing the sorting criteria, I'd also suggest to move "stalled" entries back (as non-grey entries) to the table. It should already be clear that any helper with crosses across the board is "stalled". -- Alad (talk) 19:12, 1 December 2018 (UTC)
Implemented changes in the draft, apart from the checkmarks due to accessibility concerns. -- Alad (talk) 14:15, 8 December 2018 (UTC)

Responsive tables

Moved from #Checkmarks instead of colors. -- Alad (talk) 14:14, 8 December 2018 (UTC)

The only thing that still bothers me is that even with the limit on the amount of specificities, there's so many columns in the table (especially for pacman wrappers), that on small screens every word is split by a newline. User:Morganamilo suggested to use README links instead of descriptions, but I'm not sure how that would pan out. -- Alad (talk)

User:Larivact/drafts/Template:RespCell. --Larivact (talk) 07:50, 2 December 2018 (UTC)
Thanks, it looks nice on my screen (1366x768): [11] -- Alad (talk) 13:42, 2 December 2018 (UTC)
That CSS only takes affect if your browser width is below 600px. --Larivact (talk) 14:51, 2 December 2018 (UTC)
So much for placebo effect... -- Alad (talk) 15:09, 2 December 2018 (UTC)
Yeah I was a bit confused by your response. Just to clarify tables need to be marked up differently for this to work, you can see an example in my draft. --Larivact (talk) 15:20, 2 December 2018 (UTC)
Closing this as there does not appear to be any interest. --Larivact (talk) 15:38, 22 December 2018 (UTC)

Restore sections

I seriously dislike Special:Diff/557837 because it makes the page less accessible and is semantically wrong. You should be able to link any section you like, it is the job of the users to look around when they were linked to a specific section. I think we neither can nor should attempt to make our articles idiot-proof by substituting sections with definition terms.--Larivact (talk) 08:01, 2 December 2018 (UTC)

The only way to make it idiot proof is to either delete this article or make it an alphabetical list - both of which are still very tempting to me. In any case, I don't think the separated tables (with sections or with definition terms) are ideal either - it's only there because pacman wrappers are broken to such an extent they need to be specifically warned against. -- Alad (talk) 11:44, 2 December 2018 (UTC)
One thing to keep in mind (and the reason for this "special treatment") is that the AUR helpers article is systematically abused to encourage help vampirism (resp. encouragement to ignore supported distribution tools) by users alike. I've restored the sections for now, but adding __NOTOC__ should be a consideration. It won't prevent copy pasting of links but might at least force the "AUR helpers are not supported" warning into view. -- Alad (talk) 11:54, 2 December 2018 (UTC)
[12], closing -- Alad (talk) 13:40, 8 December 2018 (UTC)

Remove "optional" distinction from File review

The description already says "by default", and I have no idea why we should encourage the notion of do-not-review-unless-opt-in. -- Alad (talk) 14:30, 8 December 2018 (UTC)

Yes, please change this. It's anyways describing a supported feature, the implication is that most tools likely offer you the ability to skip past. Also we can just remove the column entirely from the "search & download" helpers, surely... or mark them as not applicable rather than "yes". -- Eschwartz (talk) 05:52, 9 December 2018 (UTC)
Done & done. - Alad (talk) 12:00, 9 December 2018 (UTC)
Wait, are all these helpers don't-review-by-default? -- Eschwartz (talk) 15:23, 9 December 2018 (UTC)
Yes. (I tested the bunch of them back in the day, and I don't know of any changes since then.) -- Alad (talk) 16:22, 9 December 2018 (UTC)

Minor syntax error in Trizen

It is missing trailing }} in {{Y|[https://github.com/trizen/trizen/commit/9e7b40e -Ud*] to make Template:Y valid, in order to paint the background. Right now, the cell containing -Ud* is not yellow. -- Josephgbr (talk) 22:50, 31 December 2018 (UTC)

Fixed by removing template, since it is not supposed to be yellow anymore. -- Svito (talk) 05:45, 1 January 2019 (UTC)