Open MenacingPerson opened 2 years ago
It would pass the --noconfirm flag to pacman instead of piping
yes
command to it
We can't do that for package installation because pacman defaults some prompts to "no".
The workaround is to explicitly specify in your aconfmgr configuration the choices that pacman asks for, but I can't think of a panacea other than to change it in pacman (which the pacman maintainers may not be open to - presumably they made those prompts default to "no" for a reason) or use something complicated like expect
.
We can't do that for package installation because pacman defaults some prompts to "no".
I've dealt with that. Especially when a package is in conflict (wireplumber and pms).
Maybe the pacman devs can add a --yes flag that says yes to everything, even questionable choices? Or maybe they'll reject that too?
Right.
That said, if both situations can be resolved by changing the aconfmgr configuration to one such that pacman does not produce either type of prompt, then not piping yes
is less evil, so maybe we could just try that first.
Maybe the pacman devs can add a --yes flag that says yes to everything, even questionable choices? Or maybe they'll reject that too?
Well, I don't know. They might very well say that pacman is meant to be a user-facing tool and they don't want to support users who stupidly ran it with --yes
without thinking and that for automated non-interactive use cases we should build our own libalpm frontend, but that doesn't really work for aconfmgr.
That said, if both situations can be resolved by changing the aconfmgr configuration to one such that pacman does not produce either type of prompt, then not piping yes is less evil, so maybe we could just try that first.
I don't understand what you mean.
Well, I don't know. They might very well say that pacman is meant to be a user-facing tool and they don't want to support users who stupidly ran it with --yes without thinking and that for automated non-interactive use cases we should build our own libalpm frontend, but that doesn't really work for aconfmgr.
They could make it stupidly long, something like --i-am-a-machine-i-do-not-care-if-this-breaks-my-system-and-pacman-devs-have-no-liability
?
There's two relevant situations that can occur here.
The first one is the one that cd1c4b0f46c23ddf763f37f9d6c930f272690d9f attempted to address:
y
.The second one is the one seen here:
1
or the correct choice.It does look like the user has a more reliable workaround for the second situation, but maybe there's something more we can do for the first case that would not involve piping yes
.
General description of the problem:
When you use --yes, and when pacman asks to choose between 2 packages, it bugs out:
Steps to reproduce the problem:
Configuration:
Expected result:
It would pass the --noconfirm flag to pacman instead of piping
yes
command to itActual result:
It basically pipes
yes
command to itLog:
Additional context:
No response