libdpkg: Introduce frontend locking

Currently, in order to run dpkg, frontends have to release the database
lock before invoking dpkg and re-acquire it afterwards, leaving a short
time where the database is unlocked and a different dpkg process or
frontend could lock it.

Frontend locking addresses the problem by creating a "lock-frontend"
file that is acquired by the frontend and not released for dpkg
invocations. Thus, multiple frontends cannot race for the database lock.

This change extends the frontend lock to dpkg itself, acquiring it
whenever the variable DPKG_FRONTEND_LOCKED is not set, so that a user
manually running dpkg or a frontend not supporting this protocol cannot
interfere with a currently running frontend.

[guillem@debian.org:
 - Add documentation.
 - Rename frontend lock file.
 - Fix error strings. ]

Signed-off-by: Guillem Jover <guillem@debian.org>

1 files changed, 11 insertions, 11 deletions

diff --git a/doc/frontend.txt b/doc/frontend.txt
index 66280860c..9ea1e20f6 100644
--- a/doc/frontend.txt
+++ b/doc/frontend.txt
@@ -10,15 +10,15 @@ Database Locking
 ----------------
 
 Any frontend needing to make sure no write operation is currently happening,
-should lock the dpkg database by locking the file «<admindir>/lock» using
-file record locks (i.e. fcntl(2) advisory locking). The whole file should
-be locked, as that's the most portable way to perform this operation; this
-can be achieved by using start=0, len=0 and whence=SEEK_SET.
+and no other frontend is running should first acquire the frontend lock at
+«<admindir>/lock-frontend», and then acquire the dpkg database lock at
+«<admindir>/lock». When the frontend invokes dpkg, it should set the
+environment variable DPKG_FRONTEND_LOCKED (to prevent dpkg from acquiring
+the frontend lock), and then release the dpkg database lock, which will be
+acquired by dpkg itself. This way no other frontend following this protocol
+can race to perform operations while another one has one in progress.
 
-Take into account there will be a race condition between the frontend
-unlocking the database and the invoked dpkg locking it again, in which
-another process could lock it.
-
-In the future this functionality will be available through a shared libdpkg
-library, and all frontends will be expected to switch to that instead,
-because this will fix the aforementioned race condition.
+These locks must be file record locks (i.e. fcntl(2) advisory locking), and
+the whole file should be locked, as that's the most portable way to perform
+this operation; this can be achieved by using start=0, len=0 and
+whence=SEEK_SET.