On 2/15/21 8:30 PM, Allan McRae wrote:
On 13/2/21 3:21 am, Daniel Radetsky wrote:
Apologies if gmail ruins this. I'm used to github prs & don't have time to setup mutt at the moment.
If pacman is in use, makepkg -si will wait until it is available. This can be undesirable if you aren't running makepkg -si in the normal interactive way. For example, if you're running it from ansible (so shell output is supressed), and you also have a pacman -Syuw running in another terminal which you forgot to confirm, it will hang forever and you won't know why.
More generally, if you're running it in any kind of non-interactive environment, you may want it to fail fast instead of waiting for some other condition to resolve.
I'm not commenting on the patch itself, but rather the idea.
My initial reaction to this was "no". If you are running makepkg from ansible but "pacman -Syuw" manually in another terminal, you are doing many things wrong!
This waiting for pacman was added under the assumption that pacman operations are relatively short, and will eventually finish. I'm not sure the use case that a user run pacman but switched terminals and forgot to confirm the operation is something we should consider.
So, I am still leaning to rejecting this, but am open to being convinced otherwise.
The other problem I have with this in concept is, it is based on the notion that you need --nowait because you've redirected stdout/stderr for makepkg to /dev/null and you have zero ways to detect a completely infinite loop that makepkg tries hard to notify you about. This is not a use case I'm anxious to support, but... users may implement this themselves by using: makepkg && makepkg --packagelist | sudo pacman --noconfirm -U - I would consider requiring this more verbose process to be a fair tradeoff for people that have edge case needs, rather than adding a new and IMHO confusing user-interfacing option. -- Eli Schwartz Bug Wrangler and Trusted User