User talk:Svito/AUR helpers

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)

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)

Unsupported again has some other connotation, in that all AUR helpers are "unsupported" - this one is just not supported by the author. Precise terminology is more important than how lines are wrapped or general appearance. -- Alad (talk) 06:29, 25 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)

The new way of coloring "split -Syu" red or flagging optional (!) functionality yellow makes no sense either. In fact, I'm not sure why we're changing the original classification at all apart from the minor change of removing "uses". -- Alad (talk) 05:58, 25 August 2018 (UTC)

Right, the yellow color at least is incoherent. Here are 2 proposals:

a) remove yellow color, keep red when flag is enabled by default;

b) remove all colors, use another marker to differentiate optional/by default (like bold for default)

-- Spyhawk (talk) 08:53, 25 August 2018 (UTC)

I suppose b) would bury the discussion on "native pacman" once and for all. The warning under the "pacman wrappers" section should be sufficient to inform on possible unsafe behavior. -- Alad (talk) 10:02, 25 August 2018 (UTC)

[2] The markers aren't implemented yet; both * and (optional) seemed unsatisfactory. (An additional "split" makes things even harder, so I retract my complaint on a bare -Sy) -- Alad (talk) 10:24, 25 August 2018 (UTC)

That said, I don't think the emphasis on which unsafe flags are optional is important. The fact alone that the majority of pacman wrappers are willing to use them is a good indicator why we warn against them in the first place. -- Alad (talk) 10:28, 25 August 2018 (UTC)

In that case, adjusting the warning might be enough. F.e., ... may introduce unsafe flags (optionally or by default) or other unexpected behavior leading to a defective system. -- Spyhawk (talk) 11:04, 25 August 2018 (UTC)

What about move Clean build between Split packages and Unsafe flags; and Git clone between Diff view and Reliable parser. See taxonomy below (that may not make much sense and be utterly wrong). -- Svito (talk) 02:07, 25 August 2018 (UTC)

That seems redundant to me. Keep it simple. edit: unless the below is for illustrative purposes only -- Alad (talk) 05:59, 25 August 2018 (UTC)

The proposed order looks good and coherent to me. -- Spyhawk (talk) 11:05, 25 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)