Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
m (rm break)
Line 48: Line 48:
  
 
:Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=565451&oldid=565365], thanks -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 1 February 2019 (UTC)
 
:Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=565451&oldid=565365], thanks -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 1 February 2019 (UTC)
 +
 +
== Rua fails on split packages ==
 +
 +
See https://github.com/vn971/rua/issues/21 [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]])

Revision as of 14:37, 11 March 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)

clean-chroot-manager under Maintenance section

I would like to add bullet point for clean-chroot-manager under the Maintenance section. Clean chroot manager has made my life much easier for building and maintaining PKGBUILDs on the AUR. I learned about the tool on the forum but it has been available for awhile. --Dmp1ce (talk) 15:26, 30 January 2019 (UTC)

I saw the discussion in Talk:DeveloperWiki:Building_in_a_clean_chroot, but it doesn't really belong in AUR helpers either - clean-chroot-manager has no AUR-specific functionality. Furthermore, including it in #Maintenance (to verify AUR PKGBUILDs for correctness) would prioritize it over devtools.
Maybe you could do the following:
devtools — Build packages in a clean environment (systemd-nspawn container) to verify PKGBUILDs for correctness. Wrapped by aurutilsAUR and clean-chroot-managerAUR.
https://git.archlinux.org/devtools.git/ || devtools
-- Alad (talk) 15:52, 30 January 2019 (UTC)
Thanks. I felt like the tool should be mentioned somewhere because I haven't known about it for years or any other tools for maintaining a clean environment for PKGBUILD development. At this point, I'll probably just write a blog post about how I maintain PKGBUILDs. --Dmp1ce (talk) 16:15, 30 January 2019 (UTC)
"to verify PKGBUILDs for correctness" is not the right wording because the purpose of the clean chroot is not to find errors in the PKGBUIlD itself, but to ensure that the package is built correctly, linked to correct libraries etc. -- Lahwaacz (talk) 17:45, 30 January 2019 (UTC)
I added that at the last moment, feel free to change it to a more appropriate wording. -- Alad (talk) 18:11, 30 January 2019 (UTC)
In truth, it does both. :) Edit looks good anyway. -- Eschwartz (talk) 23:02, 30 January 2019 (UTC)

Aurman incorrectly flagged as having a reliable dependency solver

Aurman does not have a reliable dependency solver, the same input can result in different outputs. The comparison table inaccurately states that it does, and should be amended. —This unsigned comment is by Dkmb (talk) 14:44, 1 February 2019‎. Please sign your posts with ~~~~!

Done [3], thanks -- Alad (talk) 15:22, 1 February 2019 (UTC)

Rua fails on split packages

See https://github.com/vn971/rua/issues/21 Morganamilo (talk)