Hi Allan, On Tue, 16 Feb 2021 at 01:30, Allan McRae <allan@archlinux.org> 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.
Would you be opposed to having the wait/no-wait logic within pacman/libalpm itself? It is something that I've wanted, plus a few friends have mentioned it as well. Consider the following: - we no longer leak locking internals outside of libalpm - makepkg, tests, etc - pacman can take some time - relatively large update, slow internet connection, slow dkms builds (esp. for the nvidia drivers) The bonus point: using "pacman --wait" would greatly simplify the locking needed for archlinux-repro. The bug you mentioned a week or so ago - the fix is an extra set of nested locks for a) initial setup vs b) installing asp/devtools to fetch the PKGBUILD. Thanks Emil