Arch Linux

And how exactly do you suggest we determine ahead of time if a default wouldn't cause a failure?

In simple terms, AFAIK every prompt has one condition where it will succeed and one condition where it will fail, for example the many "Would you like to continue...thing...[Y/n]" prompts would all fail on negative responses. All the package replacements, and other conflicts fail on a negative as well. What I'm trying to say is that every prompt knows which option causes a failure. I'm not talking about "Would you like to install packages [Y/n]" knowing if it is going to run out of disk space, just the immediate effects of the prompt.

I haven't looked at the code but each prompt would probably have to give a bit of metadata.

You're asking pacman to see into the future. We don't know if there will be file conflicts until we check for them. We aren't going to do work until the user asks us to.

There are no "simple terms" here.

I'm not talking about file conflicts, (and if I am correct those don't generate a prompt anyway).

The biggest thing that I am talking about is package conflicts. When you get a (pharaphrased) prompt such as: "$PKG1 and $PGK2 are in conflict, would you like to replace $PGK2? [y/N]". It is known at the time of printing that they both can't be installed, so the default option of "no" will cause the installation of $PKG1 to fail.

It is in this case that `--noconfirm` will say no and fail but I would like an option that lets me decide.

I really do not think adding an option that makes replacements or conflict removal automatic is a good idea...

No, I think you have it backwards. It is automatic until you have to do a replacement or removal. It skips the "Would you like to continue installing these packages?" Prompts but still asks for replacements and removals. This is in contrast to --noconfirm which would say no to the removals and fail.

What is the point of that? You are going to have to watch the transaction to see if replacements/conflicts arrive, so you might as weel wait for the "y" to continue downloading that occurs directly after.

Because I would alias it so that most of the time I don't have to press anything. Right now I have noconfirm aliased but when I have to do replacements I have to call pacman without my alias. This way it would just prompt me.

I am really not convinced about the utility of this extra option, given it would only make a difference for upgrades with replaces/conflicts which are relatively rare. I'll leave this to others to make a decision on whether to implement this.

Sorry for necro, but I just finished having to unexpectedly reinstall Arch Linux and I've been Googling for this exact feature. I use a sequential script I made to do every part of installing my system that comes after rebooting into the freshly installed bootloader, and there is a lot of pacman --noconfirm in it. Something extremely annoying that I found was whenever a package conflict that I didn't remember or that wasn't there before showed up, the entire thing would fail (and only fail, because I'm smart enough to use set -e). I would then have to comment out all the lines of the script that had already run and go again, and it was a huge waste of time and effort. Having a --noconfirm option that still prompts for conflicts as Kevin suggested, or better yet a special dangerous noconfirm option called noconfirmdangerzone or something that automatically says YES to package replacements, will help a LOT the next time I have to reinstall Arch.

And, we might as well replace the noconfirm option with one that still prompts for package conflicts. If someone is using noconfirm, they're pretty much always planning to leave it sitting there unattented for a while, and even if they aren't, why is automatically quitting when a package conflict shows up EVER the desired behavior? If a given person wants to install a package, why would they EVER want pacman to just give up and quit instead of at least asking first or better yet going with a dangerous auto-yes? I would argue that whether --noconfirm is specified or not, nobody ever wants pacman to instantly exit on package conflicts without asking. 100% of the time.