Control: tags -1 + wontfix
Hi,
2012-04-28 05:31 Daniel Hartwig:
On 29 March 2012 06:53, Mario 'BitKoenig' Holbe
<mario.ho...@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
I agree with the above. In the curses/interactive mode of aptitude for
example, the update can run multiple times, including while selections
are pending to install/remove/upgrade.
aptitute cannot have the state of the system being removed under its
feet and risk performing operations in an inconsistent state, so it can
run many scripts but not those which might modify the state. The only
guarantee to do that is to have the locks on the database.
Unlocking before invoking these scripts can lead to problems if other
programs, e.g. unattended-upgrades, get the lock in between and change
the state of the system.
So I think that in principle this problem cannot be fix due to the
interactive nature of aptitude.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
