Glitches out with --yes about aconfmgr HOT 6 OPEN

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.

from aconfmgr.

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).

from aconfmgr.

Maybe the pacman devs can add a --yes flag that says yes to everything, even questionable choices? Or maybe they'll reject that too?

from aconfmgr.

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.

from 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?

from aconfmgr.

There's two relevant situations that can occur here.

The first one is the one that cd1c4b0 attempted to address:

• Conditions: aconfmgr requests pacman to install a package which conflicts with another, previously-installed package (possibly a dependency which aconfmgr doesn't directly know about).
• What happens: pacman asks if it should replace the package with the one specified on the command line (or the dependency of one).
• How to automate: answer y.
• How to work around: if we uninstall the old package first (and everything that requires it) before attempting to install its replacement, we could avoid such prompts. However, this might not be feasible in all cases. When the package in question is pinned (not a dependency), this already should be the case, as aconfmgr first uninstalls any unwanted packages before installing new ones.

The second one is the one seen here:

• Conditions: aconfmgr requests pacman to install (usually by a dependency) a virtual package, i.e. something provided by several other packages.
• What happens: pacman asks the user which package it should install.
• How to automate: answer 1 or the correct choice.
• How to work around: specify the wanted package explicitly among the list of packages to install, so pacman doesn't have to guess or ask the user.

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.

from aconfmgr.