Re: Frontend locking in APT clients

[Julian Andres Klode <jak@debian.org>]

On Mon, Jun 18, 2018 at 08:19:17PM +0200, Julian Andres Klode wrote:
> Hi folks,
> 
> With frontend locking in dpkg git, I think it's time I clear up
> some potential confusion as to how this is supposed to work in the
> APT world.
> 
> The idea is that the current _system->Lock() / apt_pkg.SystemLock
> / apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
> and lock, and new methods LockInner() and UnlockInner() will be
> provided to release "lock". Code running dpkg will need to call
> those around dpkg runs, rather than the generic Lock ones.
> 
> python-apt is currently broken in that you need to release the lock
> prior to calling commit() on an apt.Cache. This will change soon
> - no unlocking will be needed. A python-apt (>> 1.7~alpha1~) client
> should behave as following:
> 
> Basically, add Depends: python-apt (>> 1.7~alpha1~), and do:
>   with apt_pkg.SystemLock():
>     main()
> - forget about locks if you don't invoke dpkg manually - do not
> release that, ever. If you do run dpkg manually do it like this:
> 
>   with apt_pkg.NoInnerLock():
>     subprocess.check_call(["dpkg", "--configure", "-a"])

I want to note that apt in its current merge request state, 
automatically sets DPKG_FRONTEND_LOCKED when invoking dpkg
if the system lock is acquired (after the fork, directly
before the execvp). If you run dpkg yourself, like for calling
dpkg --configure -a you will probably have to set the environment
variable yourself.

So you'll need:

  with apt_pkg.NoInnerLock():
    os.putenv("DPKG_FRONTEND_LOCKED", "1")
    subprocess.check_call(["dpkg", "--configure", "-a"])


I thought about making Lock() set the variable and unlock unset
it, but I'm not sure about implicatiomns wrt other subprocesses
like hooks.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en