[Aptitude-devel] Bug#666130: Bug#666130: aptitude: locks dpkg status while running APT::Update::Post-Invoke-Success

[Daniel Hartwig]

On 29 March 2012 06:53, Mario 'BitKoenig' Holbe
<Mario.Holbe at tu-ilmenau.de> wrote:
> Package: aptitude
> Version: 0.6.6-1
>
> Hello,
>
> thanks for fixing #476399. Unfortunately there seems to be a semantic
> difference between apt and aptitude: While apt releases all locks before
> running APT::Update::Post-Invoke-Success, aptitude doesn't.
>

Hi

To say "apt releases all locks before …" is inaccurate.  Both programs
lock /var/lib/apt/lists for the full duration of the update, including
when the Post-Invoke hooks are run.

I could not find any documentation that mentions Post-Invoke is to be
run without dpkg (or anything else) locked.  It is probably best to
consider these hooks (and the equivalent dpkg hooks) as being for
notification only, not to modify any  package databases directly.

> I have an APT::Update::Post-Invoke-Success hook that runs sync-available.
> This works well with apt but doesn't with aptitude:
>

> # aptitude update
> ...
> 98% [Working]Merging available database in /tmp/apt-available.gUAoEz...done.
> dpkg: error: dpkg status database is locked by another process

'apt-get update' has no need to lock /var/lib/dpkg.

aptitude locks dpkg out of habit of being interactive;[1] it can not
have another package manager change things from under it.  Even so, it
would be possible to unlock dpkg for the time of the Post-Invoke hooks
and try to reclaim it after (and before going interactive again), but
this may lead to another process locking dpkg in the meantime.

Another interactive manager, synaptic, also locks dpkg while it runs
and during the Post-Invoke hooks.

It should be possible to work-around the interactive programs by using
Post-Invoke to notify another process (cron job or spawn a background
task which waits for the unlock) that the update has happened.  This
may not be satisfactory for you and I am open to suggestions and/or
patches (we could wait for the lock to be released if there is
contention[2]).

There is an open request for apt/aptitude to perform this on
update.[3] A general solution there would be ideal.

[1] http://bugs.debian.org/564289
[2] http://bugs.debian.org/498424
[3] http://bugs.debian.org/478970