Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
(Move warning after the intro: re)
m (Move warning after the intro: a wild newline appears)
Line 57: Line 57:
 
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 00:33, 10 May 2019 (UTC)
 
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 00:33, 10 May 2019 (UTC)
  
:I question changing the text of the warning. The article contains two "helpers" which are in the repos - devtools and aurpublish - a similar mention is already in [[Arch package guidelines]], and  
+
:I question changing the text of the warning. The article contains two "helpers" which are in the repos - devtools and aurpublish - a similar mention is already in [[Arch package guidelines]], and adding "not in the repos" is more redundant than something that adds strength to the existing warning.
adding "not in the repos" is more redundant than something that adds strength to the existing warning.
 
 
:As to the location of the warning, I would argue the reverse: move the warnings in articles like [[AUR]] up, rather than the warning here down. People acknowledging the warning may decide to not more spend any time on the topic at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:55, 18 May 2019 (UTC)
 
:As to the location of the warning, I would argue the reverse: move the warnings in articles like [[AUR]] up, rather than the warning here down. People acknowledging the warning may decide to not more spend any time on the topic at hand. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:55, 18 May 2019 (UTC)
  

Revision as of 18:55, 18 May 2019

Expand Secure criteria to include other (non-PKGBUILD) bundled files

[1], in particular [2]

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)

Yaourt is back at AUR

Mention to Yaourt was removed from this article in Special:Diff/569732 because this software was removed from AUR (Deletion request thread). However it seems eschwartz brought it back in 27/03/2019. Maybe the removal should be undone? -- Josephgbr (talk) 04:34, 14 April 2019 (UTC)

Undone, yogurt back on the list. -- Svito (talk) 21:26, 28 April 2019 (UTC)
Removed it again. Yaourt is only back because some user decided to reinstate the package, despite the upstream situation having not changed, and despite it being deleted after a valid deletion request. Otherwise, it went from zero to 5 votes this month which makes clear it lacks any sort of popularity. Similarly, there are many more AUR helpers in the AUR than those listed in the AUR helper article, but these are not included because either the authors are not interested in feedback, or because the projects lack relevance (e.g. through overly specific functionality, limited scope or being designed for ancient AUR versions).
If anything we should argue to remove helpers like aurgetAUR, aurelAUR, spinachAUR and aurmanAUR from their respective tables, as they serve only a historical purpose. That they are or are not still available as an AUR package makes no difference in this regard. -- Alad (talk) 18:41, 1 May 2019 (UTC)
My two cents: be consistent. If they are in the AUR, keep them in the table, as "obsolete", "disontinued" project have been present as a general rule if in the AUR. But I'd fill deletion request for all of them first, on the same basis yaourt was declared officially abandonned (aurman seems somewhat alive again though). Tbh, the whole situation of TU that can't agree here looks pretty stupid - I couldn't find any argument of why yaourt has been reinstated back. --Spyhawk (talk) 06:07, 2 May 2019 (UTC)
OK, I will deal with it next week. -- Alad (talk) 06:58, 2 May 2019 (UTC)
https://lists.archlinux.org/pipermail/aur-requests/2019-May/031383.html -- Alad (talk) 18:00, 9 May 2019 (UTC)

Move warning after the intro

This was previously revered due to unintended change in meaning, so I propose it here:

Warning: AUR helpers are not supported by Arch Linux developers and not present in the official repositories.
In order to be prepared to troubleshoot problems you should become familiar with the manual build process.
  • First you introduce what is AUR helpers, then provide a warning. This is consistent with AUR, Wine articles.
  • Merge warning with last intro sentence.
  • Move troubleshooting out of the warning as separate and final point in the intro.

Hopefully these make sense, wording is not changed much, except word "developer" after "Arch Linux".

-- Svito (talk) 00:33, 10 May 2019 (UTC)

I question changing the text of the warning. The article contains two "helpers" which are in the repos - devtools and aurpublish - a similar mention is already in Arch package guidelines, and adding "not in the repos" is more redundant than something that adds strength to the existing warning.
As to the location of the warning, I would argue the reverse: move the warnings in articles like AUR up, rather than the warning here down. People acknowledging the warning may decide to not more spend any time on the topic at hand. -- Alad (talk) 18:55, 18 May 2019 (UTC)

Add Raur (rust package) to the list of 'Other's at the bottom.

Hey guys! I'm the lead developer of [raur](https://gitlab.com/DavidBittner/raur). I was simply wondering if it could be added to the bottom. It seems to be more comprehensive than the existing aur.rs as it implements the entire interface, as well as all search strategies provided by the interface.

Thanks guys,

DavidBittner (talk) 00:16, 18 May 2019 (UTC) David