Hi Allan, On Tue, 16 Feb 2021 at 01:30, Allan McRae <[email protected]> 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
