[Aptitude-devel] Bug#498424: should wait for lock to be released instead of terminating

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix

Hi Jonas,

2008-09-09 22:39 Jonas Koelker:
>Package: aptitude
>Version: 0.4.11.8-1
>Severity: wishlist
>
>Here's the scenario where I want aptitude to serve me better:
>
>1. I run a dist-upgrade, chugging away
>2. I discover that I want to install something
>3. I run aptitude again while the dist-upgrade is running
>4. Aptitude fails to acquire the lock and terminates
>
>Here's the alternate step 4:
>
>4. Aptitude polls the lock until it acquires it, then proceeds.
>
>That way, aptitude is fire-and-forget instead of requiring babysitting :)

I don't think that aptitude can be used in a fire-and-forget way in many
cases.  For example:

a) aptitude or the package can fail in many ways, so even in the general
   case, it requires attention to see if the action succeeded at some
   point -- it's not completely "forget" in any case

b) the dist-upgrade or any previous commands can cause conflicts or
   other problems, requiring attention, and an automatic attempt of
   doing some other action can aggravate the consequences of anything
   going wrong in previous runs

c) the new package to be installed, or its dependencies, can fail
   because of conflicts or removals of the other packages involved in
   the previous dist-upgrade, again requiring attention/decision

d) if the new command gets stuck for some reason (e.g. because of c)),
   then other automatic tools can get stuck because of this (see
   #564289)

e) probably more, but I think that the above are serious and common
   enough to serve as an example


On the other hand, if one is so sure that all commands are going to
succeed and doesn't want to bother waiting for a very long dist-upgrade,
one can create a very simple loop in the shell to retry with a sleep
until it succeeds.  (Or type in the same terminal, so the shell runs the
second command after the first finishes).


So, in short, I think that the advantages of implement this are not
many, and there are important risks, so I am marking it as +wontfix for
now.  (But in reality, after 7+ years with no action and so many other
important problems in aptitude to solve and hundreds of bugs open, I
don't think that it's useful to keep this one open as well).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>