Talk:AUR helpers

From ArchWiki
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)

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)

proper batch interaction 2 and 3

Is there even a way to implement this feature correctly?

I do not know much so correct me if I'm wrong but the proper way to do 2 and 3 for something like wrapper repopkg aurpkg seemingly is:

  1. copy sync db and perform sync on copied db, avoiding possible partial upgrades in the system
  2. find repopkg and aurpkg using copied sync db and AUR backend respectively
  3. [user] package confirmation
  4. get all AUR package files of aurpkg and its AUR deps
  5. [user] batch inspection
  6. loop: if new AUR deps introduced get package files for those too and do another batch inspection
  7. calculate solutions using up-to-date copy of sync db
  8. [user] batch queue updates and resolutions
  9. sync sync db with its copy and perform system upgrade
    1. calculate solutions again with sync db (if sync db is different from its copy)
    2. [user] batch queue updates and resolutions again (if solutions are different)
  10. perform other package operations in resolved order
  11. build and install AUR packages in resolved order

-- 13:50, 26 August 2018 (UTC), last edited -- Svito (talk) 16:43, 26 August 2018 (UTC)

For 2/ the biggest pitfall to avoid is to calculate the solution for AUR deps on the basis of completely updated repo packages, not on the basis of the currently installed packages (f.e., the way it is done in yaourt can lead to some issues. From what I've seen, all of the other helpers (aurman, pikaur, yay) have some issues in their latest iterations with 2/, though aurman does better than the rest). -- Spyhawk (talk) 14:27, 26 August 2018 (UTC)
I agree. Maybe it is not clear but I assumed points 1-8 have to be done with up-to-date copy of sync db, not sync db and not local db (both of which remain unchanged up to point 9). -- Svito (talk) 16:08, 26 August 2018 (UTC)
Good then. This said, your solution above seems a bit over complicated to me (f.e. points 6 that should be done in 5, or 7 that should be done before 4), but I might miss something since I have never implemented batch interaction 2/ myself - I rejected the idea because of its complexity. -- Spyhawk (talk) 09:26, 27 August 2018 (UTC)

Show which unsafe flags are used by default

Batch interaction has the qualifier: An asterisk denotes functionality specifically enabled by the user.

The unsafe flags column should also do this to show what is and is not enabled by default.

There's also other solution's such as "-Sy (enabled by --foo)", but that would probably make the column annoyingly long. Morganamilo (talk)

See [7]. -- Spyhawk (talk) 09:20, 27 August 2018 (UTC)
In short, 1. I didn't like how asterisks or "optional" looked 2. it's arguably not very important anyway. Open to suggestions though, as long as it's reasonable in terms of column length (see the discussion above on small screens). -- Alad (talk) 15:00, 27 August 2018 (UTC)
There is also the option of removing the asterisk in Batch interaction. It's even less important here than in the Unsafe flags column. -- Spyhawk (talk) 16:23, 27 August 2018 (UTC)
Another option is to merge both columns and indicate what unsafe flags used for what. -- Svito (talk) 22:57, 27 August 2018 (UTC)
IDK, looks messy to me, besides that unsafe flags are not necessarily linked to batch interaction (e.g., pacman -Ud). For my part I don't mind removing the "optional"/asterisks altogether and just let the user click the myriad of links we've provided. (Not sure what happened to the links in the batch interaction column) -- Alad (talk) 23:01, 27 August 2018 (UTC)
I tried again with just asterisks, br tags and no commas here. I think we should have "optional" notation in those 2 columns as it was considered an improvement when helper has made this behaviour optional and not default and scored higher in the table. It sounds to me like a considerable detail to have documented. -- Svito (talk) 01:57, 28 August 2018 (UTC)
As far as I'm concerned, optional behavior in the unsafe flags column does not have to influence ranking anymore. All technical considerations aside, some authors have adopted optional flags not because they agreed with this practice, but because the AUR helper article is treated as some kind of religious object.
It's easier to assume that any pacman wrapper is broken by design - as hinted to by the warning - and use the unsafe flags as an enumeration of known problematic behavior. This is again similar to AUR helper#Graphical. That said, I have no real objections against Special:Diff/538110/538120 either. -- Alad (talk) 07:22, 28 August 2018 (UTC)
Merged with [8]. That leaves the alphabetical sorting. -- Alad (talk) 07:48, 28 August 2018 (UTC)
I am worried with how powerful this article have become in affecting popular opinion, Kitsunyan may get too much of user feedback of kind yay or aurman authors have received so far possibly by being in that forever cursed top spot, and for sole author of pakku that may be too much to handle. yay is probably better fit to be in top position for now in my opinion. -- Svito (talk) 09:44, 28 August 2018 (UTC)
I guess we can wait until aura v2.0 is released. -- Alad (talk) 12:00, 28 August 2018 (UTC)
Yes, fully agree. I'm also pretty sure some of the optional flags will change as default in the not-so distant future. The asterisks look fine, I guess the important point was to remove the colours, as frankly that is what is decisive for user choice. Helper users are a very simple beast... Lastly, thanks to both of you and anyone else involved for that deep rework. -- Spyhawk (talk) 09:56, 28 August 2018 (UTC)

Showing AUR comments as an important point for AUR helpers

(First, sorry that I modified the page without starting this discussion first and thank you Svito for answering kindly).

Some AUR pkgbuilds are sometimes broken and require user intervention to repair them or, more importantly, the pkgbuild is flawed, so using it as-is can be bad for the system (see qwence comment on 2018-07-08 05:01 in acroread [9]). Such information is usually available in the comments, so showing them help building the package and can improve security. Not to mention the packages that require importing GPG keys for which the author has a pinned comment to warn about it.

I don't think it should be mentioned as just a specificity of the AUR helper, but emphasized as a key feature and given its own column in the table.

—This unsigned comment is by Getzze (talk) 15:21, 5 September 2018 (UTC). Please sign your posts with ~~~~!

I am strongly inclined to delete all those comments about PGP wherever I see them. Understanding how makepkg works is not optional and this is described on the makepkg article already. People who still don't know how to handle a PGP issue should not be allowed to use the AUR, really, but enforcing that is... problematic.... Either way, there is enough learned helplessness already without actively encouraging people to think that sort of behavior is not just okay, but expected and standardized upon.
Relying on other people leaving comments is not a security replacement for reading the PKGBUILD before building it. It's actively bad for the community to emphasize these comments for this reason, as it encourages people to think that "the package is safe as long as my AUR helper doesn't show any comments".
I see no reason to rank the helpers based on this meaningless statistic, and I disagree in the strongest terms against this change. -- Eschwartz (talk) 15:39, 5 September 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)