Comment 0 for bug 1796081

[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently acquire the dpkg "lock" lock file. They need to release it before running dpkg, as dpkg also acquires it. Therefore, there is a race condition: In case the application needs to run dpkg multiple times, another application could steal the lock from under it, and the running application would fail in the middle of the install, potentially rendering the system broken.

This fixes the problem by introducing an additional "lock-frontend" file that frontends do not release when calling dpkg. When dpkg is not called by a frontend using that file, it will try to acquire the frontend lock as well, preventing it from interfering with such frontends.

[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should succeed

[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can only be expected in the form of that locking failing.

[Other info]
This is part of a wider series of SRUs for frontend locking

- dpkg (this bug)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)

Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html