Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
Line 104: Line 104:
  
 
: 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 [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:07, 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 [[User:Polygamma|Polygamma]] ([[User talk: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. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:25, 4 July 2018 (UTC)

Revision as of 20:25, 4 July 2018

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)

pikaur

Due to conflicting and non-resolvable opinions regarding how pikaurAUR handles the Native pacman column (see [1]) as well as lacking documentation about the project in general, this helper was moved from the main AUR helpers article to its discussion page.

In the unlikely event that both of these issues are addressed, the entry may be moved back to the article. -- Alad (talk) 09:09, 15 June 2018 (UTC)

Only the Native pacman in under discussion, return to the wiki and added the discussion link in this column, you should not ban completely this app for this. XavierCLL (talk) 05:07, 26 June 2018 (UTC)
Changes that led to removal of pikaur from the table were reverted and documented as was before the removal. I will re-add entry to the article exactly 7 days from now as shown below unless there will be reasonable objections made in that time period. -- Svito (talk) 18:28, 28 June 2018 (UTC)
I anticipate that after adding back the entry, it will take not take long before pikaur - misleadingly, once more - gets a green entry in the "native pacman" entry, and we can start this nonsense all over. I do hope I'm wrong and that pikaur starts behaving in the same sensible manner as all other projects have and do. If not, I can guarantee that the "emotion" I'm accused of will spread far wider than the blocking of a seldom used wiki account. -- Alad (talk) 16:49, 29 June 2018 (UTC)
Name Written In Secure Clean build Native pacman Reliable parser Reliable solver Split packages Git clone Diff view Batch interaction Shell completion Specificity
pikaurAUR Python Yes Yes Partial Yes Yes Yes Yes Yes 1, 2, 3 bash, fish, zsh dynamic users, multilingual, sort by votes/popularity, print news

"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 [2] 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: [3] -- 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 [4]). 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 [5], 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)

Add pacui to the table?

[6] pacuiAUR is kind of an aur-helper-helper. It wraps AUR helpers to provide a nice tui and also adds some of its own features. I don't really use it my self so I can't comment on how it would fit in the table/what results it would get. Just wondering if it fits here. Morganamilo (talk) 07:27, 11 June 2018 (UTC)

Seems to be aimed at Manjaro going by the amount of partial upgrade it runs (e.g. [7]) and weird stuff like "update systemd first". Former alone makes it unsuitable for inclusion in the wiki.
There's some other of these GUIs around that might fit though, like argonAUR. Not sure where to put them; a separate section perhaps? They don't really have unique functionality of their own besides a modified user interface. -- Alad (talk) 09:50, 11 June 2018 (UTC)
A new section like Pacman tips#Graphical front-ends could work. Probably wont be too useful if argon ends up being the only one that's suitable for inclusion. Morganamilo (talk) 12:37, 11 June 2018 (UTC)

Native pacman criteria and IO manipulation

Proposal summary

do not separate commands or their actions
do not suppress or force pacman behavior by using anything besides native pacman flags, e. g. by altering stdin, stdout

or (proposed in issue #201)

do not modify the pacman prompt

Latter might be overly broad as it includes --noconfirm, but it might make sense when adding "by default". Note: --ask "modifies" the prompt in the sense that it reverses it. -- Alad (talk) 09:00, 15 June 2018 (UTC)

Required package update frequency

How often does a package have to be updated to remain in 'Active'?

  • bauerbill - last update: 2017-10-03
  • aura - last update: 2017-10-07

—This unsigned comment is by J1simon (talk) 13:45, 20 June 2018 (UTC). Please sign your posts with ~~~~!

There's no criteria for this. There were, but then people would periodically update their README and call it an "update". See: [8] -- Alad (talk) 13:59, 20 June 2018 (UTC)

aurpublish fork

"Uploading" section includes questionable aurpublish fork initially added here.

Not sure why my original version couldn't be used. Also not sure why any of the changes in this version were never contributed back (though many seem fragile enough I'd never accept them).

My code was apparently licensed by @Edh under the GPL2+, a year and a half before I specified license information -- coincidentally choosing the same license. Not sure if that counts or what it means, but it does sort of tickle me pink. Who remembers to specify a license, but doesn't bother to check the licensing of external code?

Its main difference seems to be, including bloaty options to heuristically analyze the PKGBUILD and verbosely report every substring match for "http[^s]" and whether it supports https (the url _nghttp2_ver=1.31.0 doesn't, the url source+=("https://github.com/nghttp2/nghttp2/...") always did), providing parallelized upload of many PKGBUILDs at once, running updpkgsums in a semi-automated manner (something I've explicitly refused on the grounds it encourages bad habits), failure to enforce --verifysource (which I added after the silent fork I guess), and securely grep'ing the .SRCINFO rather than sourcing unknown and potentially malicious code you yourself just checked into git.

Honestly this seems to be deeply confusing to users, untested, and in the updpkgsums case just encourages bad habits.

—This unsigned comment is by Eschwartz (talk) 15:57, 24 June 2018 (UTC). Please sign your posts with ~~~~!

I removed fork from the article for now. This is definitely concerning but unfortunately not uncommon practice on GitHub where somebody forks unlicensed code and adds license file to it. Feel free to add your version of aurpublish with its description if you like. -- Svito (talk) 11:18, 25 June 2018 (UTC)
For unrelated reasons, I've been persuaded to split it out into a standalone repo, might look into it once I finish cleaning up. -- Eschwartz (talk) 18:09, 25 June 2018 (UTC)

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

[9], in particular [10]

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)