I still donât see why it should matter if the pacman step fails because another instance is running. Simply run the same yay command again and it will use the build package and install it. It is like 5 more seconds you need to invest.
Also a package manager looping all the time, until itâs the only instance left, seems like advertising bad practices and possibly introduces failures if a db lock doesnât work properly.
You didnât read my original message or two, did you 
Running it again can take HOURS for some apps.
But I found the right place to understand this issue: https://github.com/Jguer/yay/issues/2170 ! Thanks @seeji not sure how I wasnât able to find it! I also just now when I booted up, saw that thereâs a âmore about yayâ that linked there!
Also⌠an elegant solution may be to change yay to run as a user yay that can sudo with NOPASSWD. But that wouldnât be a good default for obvious reasons.
This should never be the case. The package is already built at that point and just needs to be installed.
How would that be more elegant than just using --sudoloop?
If --sudoloop times out 3 times in a row, pam picks it up as a failure and locks sudo for that user until you manually run faillock --user myUsername --reset. Iâm looking for a solution that will work not just for me.
(PS When last have you tried to build chromium-git or firefox-git? I will post here when I run into the issue that gave me my trauma, again!
)
--sudoloop keeps sudo active so the password doesnât have to rebuilt. There should be no such thing as a sudoloop timeout. That is the whole point of --sudoloop.
If you build a git project with many active commits, then if you rebuild it, there will always be new commits so it will get rebuilt. However, you donât need to rebuild it. You can simply install the package you already built. It is in your yay cache. You can install it with yay -U
Ah thatâs it! Thanks I knew I wasnât going mad
Doesnât --sudoloop just keep running sudo? The sudo command itself times out if you donât enter anything for several minutesâŚ
Yes but it does it to not allow sudo to timeout. If sudoloop is hitting a timeout condition, something else is wrong.
How can it be a major security issue for the password prompt to stay up longer?
I usually just disable timeout for sudo instead of using --sudoloop personally.
Not the password prompt to stay up longer, but the terminal having super user privileges over a long amount of time. For your PC at home it will usually be harmless, but anywhere else it could be a potential security nightmare.
Ah well, disabling the sudo password prompt timeout like i do solves the issue without the security risk. But yeah youâre right, itâs quite safe at home either way.
My personal and biased opinion - if I were in a place concerned about security, Iâd be using makepkg directly and not yay (or any AUR helper for that matter).