Difference between revisions of "User talk:Svito/AUR helpers"
(→aurman status: close) |
|||
Line 9: | Line 9: | ||
:100% agreed ;) Unfixed width for all tables and it looks better on any resolution IMO. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:56, 21 August 2018 (UTC) | :100% agreed ;) Unfixed width for all tables and it looks better on any resolution IMO. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:56, 21 August 2018 (UTC) | ||
− | == aurman status == | + | == <s>aurman status</s> == |
"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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:11, 21 August 2018 (UTC) | "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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:11, 21 August 2018 (UTC) |
Revision as of 11:41, 25 August 2018
Contents
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)
- 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)
Name aurmanAUR
(no user help)
- I would prefer (unsupported) or any label of similar size because even slightly longer labels require disabled line wrapping using w:Non-breaking space for it to look good on all screen sizes and Name column pushes other columns and last one that has most of all text now requires non-breaking spaces in result and where you should place them depends on how rows break. I don't really want to complicate formatting with a lot of
instead of whitespaces. -- Svito (talk) 23:10, 24 August 2018 (UTC)
- I would prefer (unsupported) or any label of similar size because even slightly longer labels require disabled line wrapping using w:Non-breaking space for it to look good on all screen sizes and Name column pushes other columns and last one that has most of all text now requires non-breaking spaces in result and where you should place them depends on how rows break. I don't really want to complicate formatting with a lot of
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)
- It should be clear enough if done like in AUR helpers#Graphical. -- Alad (talk) 15:29, 23 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)
- 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)
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)
- 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)
- 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)
About | Read changes | Get files | Mostly refer to build | Some of right leads to left | |||||||||
Name | Written in | File review | Diff view | Git clone | Reliable parser | Reliable solver | Split packages | Clean build | Unsafe flags | Batch interaction | Shell completion | Specificity | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Git functionality | Handle complex packages | Avoid certain practices | Input convenience |
Table legend
I copied over the legend to illustrate yet another problem: the legend is hard to use with the Search and download only table because it lacks columns (indicated in blue below).
Name | Written in | File review | Clean build | Reliable parser | Reliable solver | Split packages | Git clone | Diff view | Batch interaction | Shell completion | Specificity |
---|
I think we should therefore place these columns next to each other:
Name | Written in | File review | Reliable parser | Reliable solver | Git clone | Clean build | Split packages | Diff view | Batch interaction | Shell completion | Specificity |
---|
--Larivact (talk) 04:54, 25 August 2018 (UTC)
- I agree on the proposed grouping, apart from Diff view which relates to File review (as indicated in #unsafe flags column position). -- Alad (talk) 10:05, 25 August 2018 (UTC)