With PackageKit or pacman itself, it sometimes occurs that the lock
file is left over erroneously. A manual administrative
$ rm /var/lib/{pacman,PackageKit/alpm}/db.lck
is required.
This is also the preferred way to fix this issue as per the Wiki [1][2].
This is not really user-friendly when it happens, and has bothered me
personally about five or six times now to a point where I hacked this patch.
The lock file can now preexist when using libalpm, and libalpm now flock()s
the file exclusively. Linux ensures internally that no second exclusive lock
can be held. However, we still can't get rid of the unlink when unlocking
altogether, because existing bash scripts (e.g. makepkg.sh) depend on it.
Refactoring those to use flocks would be quite a mess, too. But because the
lock file should normally not exist without any lock on it, the scripts would
simply say that someone holds the lock. Refreshing the pacman database now fixes
the issue on it's own. This is now also user triggerable when using
PackageKit :)
[1] https://wiki.archlinux.org/title/Pacman
3.3 "Failed to init transaction (unable to lock database)" error
[2] https://wiki.archlinux.org/title/KDE
6.15 Discover stops showing updates from Arch repositories
Signed-off-by: Stephan Brunner <s.brunner@stephan-brunner.net>
5882e21806