-1

I would like to do something like this:

  1. Ask user which packages to remove interactively
  2. Remove the requested packages

And I want to keep the package system intact while getting the user input.

It is different thing to wait while some other program is changing something in the package management system than to prevent some other program from starting to mess with the package management system while my program is deciding what to do with the package management system and while doing the decided actions.

See a related bug report and comments there.

Currently there are at least two lock files used for locking the dpkg system: '/var/lib/dpkg/lock' and '/var/lib/dpkg/lock-frontend'. I try to lock using the former file by starting the following script as superuser:

#!/bin/bash
exec {var}>/var/lib/dpkg/lock
flock -n $var || { echo was locked already; exit 1; }
read -p 'Now the lock should be active. Press enter to release.'
exit

But I can still use e.g. sudo apt install, so apt does not think the file is locked.

jarno
  • 6,175

2 Answers2

2

flock(1) manages flock(2) locks, whereas dpkg and apt use fcntl(2) locks. The two types of locks are completely independent on Linux.

I'm not aware of any shell tool to do the right lock type.

To do what you want to do, write a Python script using python3-apt. This allows you to maintain a frontend lock throughout the operation, ensuring that stuff works correctly.

There is no way to do this correctly from shell, as we do not yet allow callers of apt(1) and friends to hold the frontend lock. It probably makes sense to allow that as well.

Julian Andres Klode
  • 118
1

One thing you could try is building an interceptor. Move the apt binary to another location (use which apt to find out where it is). Rename it to something like apt-old, then as root create a shell script in the location you originally had apt in, make it executable, and make it look something like this:

apt-old $@

What this will do is automatically pass any arguments you give your interceptor script on to the original apt binary, meaning that you can put anything you like before that line and it will execute it on every run, for example you can add your own file lock check:

#!/usr/bin/bash
if [ -f "/var/file_lock" ]; then
  echo "A program has superior rights to apt at this time."
  exit 1
else
  apt-old $@
fi

This would allow you to make programs calling apt to use a different file check, for one created by your program. This gives you the freedom to create it where and when you like, and still have the benefit of using apt's own file locking mechanisms.

Note that this will not disable the original apt binary, you're only moving it so that your script takes its place in the path.

Minty
  • 1,228