src/common.bash: Translate --yes into --noconfirm

[AleksanderBobinski]

TL;DR - I think I found a bug and fixed it. Please let me know if you think this is OK since I'm essentially removing one of your old commits and if a regression test is needed.

Currently the handling of the --yes option seems slightly unintuitive. Pacman's questions will only be responded to with "yes" but as a comment in the code nearby states sometimes a "no" is the default action to take.

There is also a subtle bug here, sometimes the default response is neither "yes" nor "no". For example when multiple packages fulfill the same dependency pacman will ask to select a package by typing in a number. Here aconfmgr fails to do the right thing. Instead of aborting on an invalid answer pacman will ask the question again and cause aconfmgr to be stuck in an endless loop.

The fix for this issue is to make pacman always use the default action by passing "--noconfirm" if aconfmgr was started with "--yes".

Regarding the already existing "--confirm" that was introduced in cd1c4b0: "common.bash: Automate pacman prompts more aggressively", the pacman man page states that "--confirm" only cancels a previous "--noconfirm" flag. Throw "--confirm" away.

The specific error that's fixed:
$ aconfmgr --aur-helper yay --config ./ apply --yes
(...)
::: Installing 375 missing native packages.
resolving dependencies...
:: There are 2 providers available for qt6-multimedia-backend:
:: Repository extra
1) qt6-multimedia-ffmpeg 2) qt6-multimedia-gstreamer

Enter a number (default=1): error: invalid number: y

Enter a number (default=1): error: invalid number: y
(...)

This also fixes potential issues that might arise if "--yes" is used with non-english languages that will cause pacman to expect a word different than "yes" as confirmation.

[CyberShadow]

Pacman's questions will only be responded to with "yes" but as a comment in the code nearby states sometimes a "no" is the default action to take.

Yes, that's the problem.

https://gitlab.archlinux.org/pacman/pacman/blob/39c3cbdf56a2180dfc3102d49634b40264112bc0/src/pacman/util.c#L1617

With this change, if pacman asks a yes/no question with the default being "no", it will choose "no", which will cause it to exit.

:: There are 2 providers available for qt6-multimedia-backend:

IIRC, the way to fix this is to add your choice explicitly to your aconfmgr configuration. Then, pacman will not ask this question.

[AleksanderBobinski]

I see, before I abandon this PR allow me to ask. In which specific use-case does pacman exiting due to a default "no" cause a problem?

Maybe there is an easier way to deal with that use-case instead of rejecting all defaults.

[CyberShadow]

The full list: https://gitlab.archlinux.org/search?search=noyes&nav_source=navbar&project_id=19637&group_id=24&search_code=true&repository_ref=master

but IIRC the particular situation was when a new package provides the functionality of an existing, installed package. I don't think aconfmgr has a way to tell pacman that the operation is intended and it should proceed with it; and it does have to be done in a single pacman invocation, so removing the previous package beforehand is out.

[AleksanderBobinski]

Ok, I'll look into that, thank you.