← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1795614] Re: packagekit frontend locking

 

This bug was fixed in the package packagekit - 1.1.9-1ubuntu2.18.04.3

---------------
packagekit (1.1.9-1ubuntu2.18.04.3) bionic; urgency=medium

  * Pass --no-restart-after-upgrade to dh_installsystemd to avoid PackageKit
    restarting while upgrading under PackageKit (LP: #1790613)

packagekit (1.1.9-1ubuntu2.18.04.2) bionic; urgency=medium

  * debian/patches/frontend-locking.diff:
    Implement frontend locking in a simple way. Will need some more
    work to upstream, and possibly some error checking. (LP: #1795614)
  * Bump libapt-pkg-dev build-dep to >= 1.6.5~ for frontend locking
  * debian/patches/aptcc-Fix-invalid-version-dereference-in-AptInf-prov.patch,
    aptcc-removing-duplicate-delete-call.patch:
    Fix invalid dereference and delete wrong (duplicate) "delete"
    statement in providesCodec (LP: #1790671)

 -- Julian Andres Klode <juliank@xxxxxxxxxx>  Mon, 15 Oct 2018 15:46:47
+0200

** Changed in: packagekit (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1795614

Title:
  packagekit frontend locking

Status in packagekit package in Ubuntu:
  Fix Released
Status in packagekit source package in Xenial:
  Fix Committed
Status in packagekit source package in Bionic:
  Fix Released
Status in packagekit source package in Cosmic:
  Fix Released

Bug description:
  [SRU Notes]

  [rbasak] Requires apt 1.2.28 (Xenial) and 1.6.5 (Bionic), both of
  which are currently in proposed. Do not release to updates without
  releasing the newer apt first.

  [Impact]
  PackageKit needs an adjustment for frontend locking, so it does not release the frontend lock during dpkg invocations, but only the normal dpkg lock.

  Frontend locking prevents race conditions between multiple dpkg
  frontends, which can cause other frontends to be interrupted while
  they are installing stuff - the frontend loses the dpkg lock between
  dpkg runs and the system ends up in a partially configured state.

  See bug 1781169 for more details on frontend locking.

  [Test case]
  1. Install a package
  2. Modify prerm to sleep
  3. Remove package via pkcon and check that packagekitd process holds lock-frontend and dpkg holds lock (we release lock by closing the lock files, so just check if the files are open).

  [Regression potential]
  Changing the code to call UnLockInner() vs UnLock() makes it do less steps and only release "lock" as before, and not "lock-frontend". That should not be causing any regressions.

  The patch also adds a call to LockInner() after the dpkg execution to
  make it reacquire "lock", this could fail. It should not have much
  impact however, as it only affects a single transaction AFAICT. It
  does reduce the risk of some frontend not implementing frontend
  locking from racing while we still hold the frontend lock, though.

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1795614/+subscriptions


References