It would be nice to have a lock argument in the apt.cache.Cache.update()
and apt.cache.Cache.commit() methods.

It would allow to pass the fd (int) of an already acquired lock. The
corresponding methods won't try to get a lock on lists/archives if it's
given.

The packagekit backend and aptdaemon try to acquire the locks
before executing the tasks to give the user an idea which application
should be closed before the task can be performed, instead of failing
during the task.

So currently I have to acquire the locks at the start of a
transaction, release it again shortly before call e.g. Cache.update()
and re-aquire them again afterwards until the transaction is done.

Here is small patch for the current debian-sid branch.

tag 596793 confirmed
thanks

In contrast to you, I prefer a property returning an apt_pkg.FileLock
object, which can then be used like:

	with cache.archive_lock:
		cache.commit()
		cache.update()

	# or (possibly with better names)
	cache.archive_lock.__enter__()
	cache.commit()
	cache.update()
	cache.archive_lock.__exit__()

Looks a bit more natural, although there is currently no way to get
the fd from the lock (this could be added, though). If called outside
a with block, the functions are the lock themselves (FileLock does
reference-count based locking).

Scheduled for wheezy.

You have to keep in that in most cases you have to acquire more than
one lock. E.g. for commit, you should hold the archive and dpkg status
lock. And they have to be raised in a special order to avoid races
with e.g. apt-get.

That is why I decided to always hold all three locks for an
aptdaemon transaction (archive, status, lists) and implement an
high level lock.

See http://bazaar.launchpad.net/~aptdaemon-developers/aptdaemon/main/annotate/head:/aptdaemon/lock.py

The idea with the context manager is very nice.