Regarding stable releases. I plan to backport the dpkg, apt, and python-apt changes to bionic and xenial. It will be worth it, and together with a fix in u-u and aptdaemon and packagekit, we will be looking at I guess 99% of issues with lock races fixed.
While I'm at it, 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. On Mon, Jun 18, 2018 at 08:20:04PM +0200, Julian Andres Klode wrote: > Forwarding this to ubuntu-devel. > > ----- Forwarded message from Julian Andres Klode <[email protected]> ----- > > Date: Mon, 18 Jun 2018 20:19:17 +0200 > From: Julian Andres Klode <[email protected]> > To: [email protected], [email protected] > Subject: Frontend locking in APT clients > Message-ID: <[email protected]> > Accept-Language: de-DE, de, en-GB, en-US, en > User-Agent: NeoMutt/20180512 > > 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 > > ----- End forwarded message ----- > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
