Frontend locking in APT clients

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

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"])

or instead of context managers, use the functions
pkgsystem_{un,}lock{,_inner}.

This will ensure that your apt client will be safe against
any other apt client, and any other client implementing frontend
locking. It will not be safe against other frontends that acquire
the dpkg lock themselves, those will need fixing too. It will however,
be safe against concurrent runs of dpkg by users or frontends not
implementing locking.

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