group.of.nepali.translators team mailing list archive

[Julian Andres Klode <1795614@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

[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.

[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.

** Affects: packagekit (Ubuntu)
     Importance: Undecided
         Status: Fix Released

** Affects: packagekit (Ubuntu Xenial)
     Importance: Undecided
         Status: Triaged

** Affects: packagekit (Ubuntu Bionic)
     Importance: Undecided
         Status: Triaged

** Affects: packagekit (Ubuntu Cosmic)
     Importance: Undecided
         Status: Fix Released

** Also affects: packagekit (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** Also affects: packagekit (Ubuntu Cosmic)
   Importance: Undecided
       Status: New

** Also affects: packagekit (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: packagekit (Ubuntu Cosmic)
       Status: New => Fix Released

** Changed in: packagekit (Ubuntu Bionic)
       Status: New => Triaged

** Changed in: packagekit (Ubuntu Xenial)
       Status: New => Triaged

** Description changed:

  [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.
  
  [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
+ 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.

-- 
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:
  Triaged
Status in packagekit source package in Bionic:
  Triaged
Status in packagekit source package in Cosmic:
  Fix Released

Bug description:
  [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.

  [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.

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