`Native Pacman` criteria

[actionless]

(instead of passing those to class constructor)

that should allow to control the current flow of executed app from python code (not only from user's stdin input as it is now) so make it possible to interactively wrap -Syu

however in case of manual package selection ([m] choice in prompt) N reply will be sent to -Syu and -Su --ignore <interactively_ignored_package> or -Su <interactively_added_package> command will be fired depending on user choice

@AladW are the last 2 paragraphs sounding fine to you? [m] is not default behavior, so by default -Syu will be wrapped accurately

[actionless]

then it really looks like a coincidence (you first introduced --do_everything to me in a conversation in the context of batch interaction so it was logical to assume what the reasoning to create that flag was related to batch interaction topic, not to resolving conflicting package names)

but anyway pikspect was introduced not to solve Syu separation topic but to provide a safer alternative to --noconfirm and --ask pacman flags (i've decided to implement full Syu wrapping using that module only because it was not so hard when i already had that code for a different purpose)

and thanks for sharing the details about your beard

[AladW]

For --ask, see https://wiki.archlinux.org/index.php/Talk:AUR_helpers#Native_pacman_criteria_and_IO_manipulation

Now while I disagree with saying overly mean things like Alad often does, he has a point

I'm an asshole at times, but unlike our friend here I've always been interested in collaborating with other users, rather than engage in some "battle of the helpers" where anything brought up by the opposing party is dragged through the mud.

It should be pretty obvious by now that anything concerning pikaur that does not exactly fit the author's ideas is a dead end and the wiki reflects that state accordingly.

[actionless]

i would like to participate in defining new criteria since during doing research on pikaur i found what using --ask and --noconfirm flags sometimes could lead to unexpected result (whatever it being done with -Syu or with -U when installing AUR-built package) and that's the reason i've chosen the approach where pacman always running in interactive mode (unless --noconfirm arg was fed explicitly) and answers which were batch-collected from user few steps before are re-fed to pacman interactively (so in any unexpected situation user can answer pacman's questions on his own).

So my point what IO manipulation is much safe (in situation where AUR helper was not able to predict pacman's questions correctly) than forcing pacman to run in non-interactive mode.

https://wiki.archlinux.org/index.php?title=Talk%3AAUR_helpers&type=revision&diff=525701&oldid=525698

no comments

[AladW]

I've given you numerous warnings before yet you keep coming up with new personal attacks, be that directly or through weird accusations such as https://github.com/actionless/pikaur/issues/201#issuecomment-396315476, and discuss in circles. So I've indulged you and blocked your account.

Regardless of that if you elaborate on your "unexpected result" in this issue I'm sure the other helper authors are all ears.

[actionless]

Except when pikaur fails in the middle or makes some other mistake

my point what other aur helpers could also make some mistake, not only pikaur

and so if pikaur makes mistake -- user will have to answer the pacman's question on his own

if aur helper which use --noconfirm will make mistake -- pacman could stop with some error

if aur helper which use --ask will make a mistake -- some random pacman's answer could receive a confirmative answer

[Morganamilo]

You keep trying to show how good this feature is but really I don't think that's relevant. As I said above:

The problem is not if it's better or worse than other methods. Simply that this method still interferes with pacman by altering how it runs a command. Which means you don't meet the criteria for native pacman.

[actionless]

but we are discussing here the new criteria for native pacman, since i banned in arch wiki for made-up reasons and so can't post there

so it doesn't make sense to refer in conversation to the old criteria

[AladW]

for made-up reasons

lol. you really are a hopeless case comrade... all the best.

[polygamma]

I see your point, @actionless, if an aur helper does not detect e. g. an upcoming conflict, and --ask is being used, a package will be removed, without the users confirmation. i am going to make --ask usage optional and non default

[actionless]

Even though pikaur technically calls -Syu it sill effectively splits the actions.

that point is still not valid, there is no any split — pacman db is stays locked all the time

if prompt is a "split" — then pacman is splitting those commands, but not me, i am not sending to it any SIGSTOP/SIGCONT (and even if i would do — that still is guarded by pacman db lock so nothing could affect db state while those actions are "splitted")

[SpineEyE]

@actionless what do you think about calling -Syu again in case the user typed m?

Edit: Technically the user could be taking several minutes to hours to ignore package X while in m mode and then when you call pacman -Su --ignore X, pikaur would do a partial upgrade. So you could solve this with the above.

[actionless]

@SpineEyE if user typed m it will just -Su without doing -y (--refresh) again

the reason -- to avoid installing packages which were not shown in the prompt if more updates appeared in the repositories during [m]anual package selection

[SpineEyE]

Apparently everyone else thinks that calling aur_helper -Syu --ignore X is an option, while how you implemented it, it's not an option, although the user obviously has to delete packages from being updated, so this is clearly an option and not automatic. To be clear, I find this whole discussion incredibly focusing on syntax.

[AladW]

I see your point, @actionless, if an aur helper does not detect e. g. an upcoming conflict, and --ask is being used, a package will be removed, without the users confirmation. i am going to make --ask usage optional and non default

In that case batch interaction as it is defined now is probably a futile (or even harmful) endeavour.

[AladW]

https://wiki.archlinux.org/index.php/Talk:AUR_helpers#Relax_batch_interaction_criteria

[AladW]

Note that contrary to --ask I don't see how pacman --noconfirm is harmful in general, since it defaults to "no" on most questions in particular conflicts.

[AladW]

@Morganamilo what do you think? Afaik only yay, pacaur and aurman use --ask.

[Morganamilo]

Nope Yay uses ask too. I already left my reply on the wiki.

[AladW]

Left a note if pacinstall might be a better/safer approach with the same result.

[actionless]

why batch criteria should be relaxed? i think that's actually a real state of things by now: both batch interaction and native pacman wrapping are not fully possible.

why not to show in the table what some helpers are better in batch interaction and other following native pacman criteria more strictly?

[AladW]

Calling it impossible just means people didn't think it through enough in my book.

[Morganamilo]

A solution to both problems is currently undiscovered then ¯\_(ツ)_/¯

[AladW]

So bottom line:

• Add --ask to potentially harmful commands
  • Proposal: add a link to pacman git commit describing what it does
  • Unclear: "equally harmful" as -Ud or -Rdd
• Remove color from batch interaction column
  • While some clarification can be given in the table, AUR helper authors should explain what it does / give pro and cons
  • Leave out pacinstall until we know what it does or is more widely used

I'll start out implementing some of these, feel free to assist.

[polygamma]

I'd say --ask is not as harmful as -Ud or -Rdd because even if the conflict detection etc. has been correct, -Ud is still possibly harmful. If you use -Udto install a package, of which you want to install the missing deps later on, and building of a package etc. fails, well, you broke the system.

[Morganamilo]

That was my point exactly on the wiki.

[polygamma]

Sorry, @Morganamilo - did not read that entry.

[AladW]

Something else, if we don't color the Batch column something more descriptive like "Yes" or "No" might be in order. E.g. number the criteria and just put 1), 2) in there

[Morganamilo]

how about:

• Prompts before each build for every package
• Prompts ahead of time, issues like conflicts will be prompted before each build
• Prompts ahead of time. Never prompts during build.

[AladW]

Sounds good to me. Maybe also mention that "viewing PKGBUILDs" is also a prompt

[polygamma]

Good idea, but why should the prompts appear before the "build" and not before the "install"? If you let pacman do it's thing, the conflict questions do arise when installing. Unless you use makepkg -s

[Morganamilo]

Well i was including pkgbuilds and seeing the dependency chain and such. The wording can be improved though.

[polygamma]

Addition: One should list for every bullet point, which one is the default behavior, and which can be achieved via options.

[AladW]

Yeah, I guess the "before the build" was another point of contestation in this and similar issues, you might as well generalize it.

[AladW]

Addition: One should list for every bullet point, which one is the default behavior, and which can be achieved via options.

For pacman/makepkg I agree, but what the "default" is for inspecting PKGBUILDs depends on the design of the helper, right? The old-fashioned way is viewing a PKGBUILD before each build, pacaur and following show all the PKGBUILDs before doing anything else. Unless you mean something else.

[polygamma]

Those bullet points are still quite tricky. e.g. currently aurman offers 4 possibilities regarding batch interaction.

1. no --ask=4 usage and no usage of --do_everything (default behavior): In case of aurman -Syu there are pacman prompts because of pacman -Syu, after that aurman prompts for conflicts, deps, PKGBUILDS etc. and for every "chunk" of packages confirmations of installations and/or conflicts, which are the normal pacman prompts.

2. no --ask=4 usage and usage of --do_everything: aurman is handling -u, so only pacman -Sy is being called in the beginning, thus no pacman prompts there, after that the normal aurman prompts and finally the pacman prompts for the installations/conflicts

3. --ask=4 usage and no usage of --do_everything: pacman in the beginning (pacman -Syu), after that aurman once, furthermore no additional pacman prompts.

4. --ask=4 and --do_everything: One time aurman prompts, after that no more prompts.

addition: current explanations for those options: --ask=4 and --do_everything

[Morganamilo]

I think the bullets points should be quite general. They shouldn't mention implementation at all.

EDIT: Maybe they can mention examples of implementation. But don't actually tie anything to implementation.

[polygamma]

How about the following:

• Batch interaction of PKGBUILDs, means: Inspect all PKGBUILDs at once, before building of packages start. Notice: Building, not installing, hence a normal pacman -Syu call in the beginning does not negotiate this.
• Summarizing overviews of pacman and the AUR Helper in case of -u usage, so that there are not pacman prompts in the beginning, and after installing some packages another overview of the AUR Helper. This implies "splitting" of -Syu to -Sy and other things, we all know what is meant by that at this point, even if we have not found a good wording.
• No redundant confirmations for installations and/or conflicts, which means: If you have confirmed an installation for the AUR Helper, pacman does not ask again.

Addition: For aurman it would be:

First bulletpoint: Always Second bulletpoint: With --do_everything, which is not enabled by default Third bulletpoint: With use_ask config option, which is not enabled by default

[Morganamilo]

Is the Batch interaction of PKGBUILDs, means: meant to be outside the bullets points?

[polygamma]

Those should be three different bullet points all in all. The exact wording is for this GitHub issue only, to make clear what I mean.

Edit: I am not good at finding short, eloquent english expressions ;)

[AladW]

Sounds great. So aurman/yay/pikaur would have 1,2,3 while aurutils would have 1 for example.

[Morganamilo]

Are these going to be the available options or the defaults?

[AladW]

Is there anything speaking against "available options"?

[polygamma]

I guess one should list, whether those are available by default or only with a specific option. Maybe append a link to the specific options needed, if they are not enabled by default. Makes it really clear for the user, what is going on

[AladW]

How about 1,2*,3* if 2 and 3 are optional?

[polygamma]

Good idea!

[Morganamilo]

Sure.

[AladW]

Great, then now for the hard part on writing eloquent expressions. :smile:

Until that's done we can figure out where to put a note on --ask; I see the point https://github.com/actionless/pikaur/issues/201#issuecomment-396666851 now but then it doesn't really make sense to put it in the same sentence as pacman -Rdd. Options:

• Add a note to the batch interaction description that helpers using --ask to achieve this cannot reach full marks in native pacman
• Add a third bullet to native pacman description
• Expand the first bullet that describes separation of commands
• Other options?

[polygamma]

Add a third bullet to native pacman description, explaining the problems of "--ask" usage.

Also: Mark it, where it is relevant. In the case of aurman that would be the third bulletpoint for "batch interaction", because well, that's where it's being used. The note should state, that enabling that feature of "aurman" negotiates "native pacman" with a link to the newly created third bullet of the "native pacman" description.

[AladW]

NB. Preliminary wording for batch interaction column: https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=525816&oldid=525791

"ability to prompt in direct succession" seems accurate enough.

[polygamma]

For point 3: You should not forget the confirmations of installations. It's really "conflicts and installations".