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