User talk:Svito/AUR helpers

From ArchWiki
Jump to navigation Jump to search

Search only

From User:halosghost: Search/Download-only could be a good section title, because some of these tools support package downloads as well. -- Alad (talk) 21:56, 21 August 2018 (UTC)

Fixed table width

Maybe a smaller or no fixed width? The GUI table (AUR helpers#Graphical) is not 100% either. -- Alad (talk) 19:58, 21 August 2018 (UTC)

100% agreed ;) Unfixed width for all tables and it looks better on any resolution IMO. -- Svito (talk) 20:56, 21 August 2018 (UTC)

aurman status

"Closed development" is more accurate than "Not for public use" in aurman's Notes. Anyone can use aurman by installing the AUR package, they just can't participate in development. -- Alad (talk) 22:11, 21 August 2018 (UTC)

Note that bauerbill fits the criteria of "closed development" too. I'd also suggest keeping pacaur in a separate table, or removing it entirely - unlike the others, it's officially deprecated -- Spyhawk (talk) 19:02, 22 August 2018 (UTC)
I don't like this suggestion, it's overly complex and makes a big deal out of small details.
Also bauerbill isn't "closed" in the sense aurman is, since anyone can leave requests on the bauerbill forum page. -- Alad (talk) 22:05, 22 August 2018 (UTC)
Just to be clear do you think so of Special:Diff/536803/next as well or only of Spyhawk suggestion?
I checked recent Xyne posts and homepage myself and he accepts suggestions via email and forum so I did not move it. -- Svito (talk) 22:36, 22 August 2018 (UTC)
I'd still use a better indicator for discontinued projects (extra column, or bold 'discontinued' text? Strikethrough on the package name works great too). -- Spyhawk (talk) 08:02, 23 August 2018 (UTC)
The bold discontinued/private looks good to me. -- Alad (talk) 15:26, 23 August 2018 (UTC)
From #archlinux: aurman is not "private" in the sense that the source code is still available to anyone. -- Alad (talk) 17:40, 24 August 2018 (UTC)
Name
aurmanAUR
(no user help)
What about this one? -- Svito (talk) 19:26, 24 August 2018 (UTC)
Maybe the more formal "no user support"? -- Spyhawk (talk) 21:24, 24 August 2018 (UTC)
Works for me. -- Alad (talk) 21:39, 24 August 2018 (UTC)

pacman wrappers and unsafe flags

I think using a separate section for pacman wrappers deals with the problematic perfectly. However, I'm unsure if issues should be included in the Specificity column (as done for yaourt below; splits -Syu is missing for some entries). The column is to the far right of the table and may be overlooked. That said, a second column might be overkill. I wonder what incorporating remarks on pacman wrapping in the Name column would look like. Alad (talk) 19:53, 21 August 2018 (UTC)

Changed Specifity to Notes, added split pacman -Syu and colored helper column accordingly. Thanks for all feedback! -- Svito (talk) 21:06, 21 August 2018 (UTC)
I think the colored table headers are confusing because it's not obvious what the colors mean. I'd prefer a dedicated column. --Larivact (talk) 04:22, 22 August 2018 (UTC)
It should be clear enough if done like in AUR helpers#Graphical. -- Alad (talk) 15:29, 23 August 2018 (UTC)
I think doing it that way would be less clear and just unnecessary visual complication, if we have 12 columns, we can just as well have 13. --Larivact (talk) 15:36, 23 August 2018 (UTC)
In that case we should find a better name than "Bad wrap"... -- Alad (talk) 16:35, 23 August 2018 (UTC)
Dangerous splitting? --Larivact (talk) 16:42, 23 August 2018 (UTC)
Well, that doesn't handle the installation/other case (like -Ud for pacaur)... -- Alad (talk) 16:50, 23 August 2018 (UTC)
Unsafe practices? --Larivact (talk) 16:57, 23 August 2018 (UTC)
Unsafe flags is fine to me. Though uses may now be redundant, and we can just list the flags directly. -- Alad (talk) 07:19, 24 August 2018 (UTC)

The warning on pacman wrappers could probably be included here, instead of the criteria. -- Alad (talk) 19:54, 21 August 2018 (UTC)

pacman wrappers warning

Not sure if "such usage" in the warning is clear enough. It could mean "usage of pacman wrappers in general" or "use of pacman wrappers for packages in the official repositories. Note that latter does not handle the common case of AUR packages with repo dependencies - the installation of said deps will also be wrapped. If nobody has arguments against I'd thus go with an explicit "usage of pacman wrappers". Some reference to the "Bad wrap" (or whatever column name we decide on) could also be made. -- Alad (talk) 16:38, 23 August 2018 (UTC)

This opens another can of worms: some helpers are optionally pacman wrappers, like bauerbill and pkgbuilder which include separate programs for this functionality. I'm not sure they'd fit under "AUR only" though. -- Alad (talk) 16:58, 23 August 2018 (UTC)
Or perhaps not, since "bad wrap" is only relevant if it does so by default. -- Alad (talk) 17:10, 23 August 2018 (UTC)
I don't feel "by default" is presented in an explicit manner, especially in regards to the wrappers that don't use bad wraps even as option. Maybe use something like "not by default" where relevant instead? Or an asterisk with the "*not be default" below the table? -- Spyhawk (talk) 09:50, 24 August 2018 (UTC)
I guess this is covered by "Optional" now. -- Alad (talk) 16:22, 24 August 2018 (UTC)

unsafe flags column position

I'd set the "Bad wrap" column right of "File review", since latter is more important in terms of safety (besides looking somewhat neater with other tables starting in "File review" as well). -- Alad (talk) 16:49, 23 August 2018 (UTC)

This is what it looks like: [1] -- Alad (talk) 17:23, 23 August 2018 (UTC)
I'm no longer convinced this actually looks better though. More opinions? -- Alad (talk) 17:36, 24 August 2018 (UTC)
The potentially unsafe flag column is closely related to Batch interaction. Maybe move it to the end instead? In the end, it doesn't matter which order it is displayed. Also, to keep it simple, yellow color could be used for optional flags, red for enabled by default, green for no unsafe flag at all. -- Spyhawk (talk) 18:12, 24 August 2018 (UTC)
Would it be better to the left or right? -- Svito (talk) 19:08, 24 August 2018 (UTC)
I'm not sure which is better, but I noticed that split -Syu now mentions "-Sy". Unless you know the context beforehand (which you don't since we removed the criteria), this implies the helper runs partial upgrades, which is not necessarily the case when -Syu is split to -Sy and -Su. -- Alad (talk) 19:51, 24 August 2018 (UTC)
Also, the multi-coloured system (now with orange) has become so complicated that it has become pretty much meaningless imho. If the table is a tool for users to get a quick overview and motivate authors to not use *potentially* unsafe commands (but which are not necessarily depending on the implementation), use red when it's enabled by default, as a deterrent. No need for too much technical distinction that only authors can fully understand and argue about, it's not the point of the table. Lastly, I'd also move the "Diff view" next to "File review" since they're strongly related. -- Spyhawk (talk) 21:09, 24 August 2018 (UTC)