[pacman-dev] [PATCH] Adds a --nowait option

Daniel Radetsky dradetsky at gmail.com
Wed Feb 24 04:05:01 UTC 2021

I realize that my own use case may seem like a very unlikely set of
circumstances, but I don't think it's that crazy if you generalize it
a bit.

The point is that running `makepkg -si` from ansible isn't impossible.
Sure, maybe you shouldn't do it, but people will.
Ansible suppresses stdout/stderr. This is 100% WONTFIX as far as the
ansible people are concerned. So saying that
makepkg is trying very hard to tell you about it's infinite loop isn't
really very satisfying.

Now, I can't be the only person who's ever had a stray lockfile left
around by a pacman operation that went wrong.
Like I was midway through downloading a bunch of updates and my laptop
ran out of power of something. It happens.
Now I can fix this on my laptop easy enough, but the use case for
ansible is keeping my 80 servers in sync. The
idea that one of these is going to have a stray lockfile from
something going wrong isn't inconceivable. But as far as I
can tell, there's no way to say `pacman --am-i-locked-if-so-exit-1`.
Which is maybe what we actually want here; it's fair
enough to expect the guy writing ansible scripts to know how to record
variables from commands, to be able to look up
this flag in the pacman manual page, and only proceed with makepkg if
the test is ok.

What I don't think is desirable is requiring our hero to manually test
for the existence of /var/lib/pacman/db.lck. For one thing, I
don't think this file is referenced anywhere in the pacman
documentation. It's not in any of the man pages. `man -K db.lck` turns
up nothing. Frankly, I don't even remember how I know about it.
Probably I poked around trying to fix a bad lock & found it.

I'm not sure Eli's workaround meets the case given that we're talking
about running `makepkg -si`. It would work if
there were no deps & I didn't have to run `makepkg -s && makepkg
--packagelist`, but if I do, I think this will infinite loop
just as much as otherwise, since both pass through run_pacman.

Frankly, I'm not really sure why waiting in a loop for pacman to
unlock forever is even desirable to begin with.
I tend to think it should just fail fast. This prevents this whole
journey of discovery from occuring in the first place.
We never have to figure out why it's looping forever. But given that
it already works this way, a flag to disable
it seems reasonable. Or a way to just ask pacman if it's locked. Or something.

For example, if you were to move the looping logic into pacman itself,
and I could set an env var which would
ensure that it didn't loop, that would probably work.

More information about the pacman-dev mailing list