--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: message should mention other solutions to 'dpkg was interrupted'
- From: jidanni@jidanni.org
- Date: Wed, 25 Sep 2013 19:08:11 +0800
- Message-id: <87a9j1p3ac.fsf@jidanni.org>
Package: dpkg
Version: 1.17.1
Severity: wishlist
This message assumes the user wants to continue the operation:
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
But there is also a good chance the reason dpkg was interrupted was due
to the user purposely interrupting it in order to back out of what he
was doing.
Therefore the message should also mention what to do in that case.
Here's a scenario:
User does
aptitude safe-upgrade
says Yes
then realizes that what is about to happen is not what he wants.
He hits ^C, but that is ignored (by design. OK.)
He goes to another window and does killall aptitude.
Now when he does aptitude safe-upgrade again he gets
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
W: Could not lock the cache file; this usually means that dpkg or another apt tool is already installing packages. Opening in read-only mode; any changes you make to the states of packages will NOT be preserved!
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
So perhaps add "Or try dpkg -i Current.deb on any half installed packages
(found by dpkg -l) that you don't want to upgrade to New.deb" or
something like that.
--- End Message ---
--- Begin Message ---
On Wed, Sep 25, 2013 at 3:02 PM, Guillem Jover <guillem@debian.org> wrote:
> On Wed, 2013-09-25 at 19:08:11 +0800, jidanni@jidanni.org wrote:
>> This message assumes the user wants to continue the operation:
>> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
>
> This is not a dpkg message, that's coming from (lib)apt.
>
>> But there is also a good chance the reason dpkg was interrupted was due
>> to the user purposely interrupting it in order to back out of what he
>> was doing.
>>
>> Therefore the message should also mention what to do in that case.
^C isn't blocked, it is noticed and the operation is interrupted at the
next point where it is (relatively) safe to interrupt the operation
(aka: at the end of the current dpkg run).
Whatever problem you are trying to solve by interrupting dpkg forcefully,
it usually means that you have (at least) two problems after it
(e.g. Maintainerscripts e.g. are supposed to be idempotent, but given how
many are buggy in normal circumstances, I wouldn't be surprised if they
explode in a spectacular fashion in untest(ed/able) situations – and
downgrades aren't supported, so a preinst script could have started an
upgrade already which can't be undone, even if it is idempotent).
Just reinstall the removed packages (conf-files aren't removed by default)
and/or restore from your backup if you don't like the result, everything
else is just bound to fail. It might work a few times or even many times,
but not always (– which gives the wrong impression of a safety net).
There is a reason why dpkg frontends are asking if what they want to do is
okay before they do it: It is your last and only chance to back out.
So use your chance wisely.
>> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
>>
>> So perhaps add "Or try dpkg -i Current.deb on any half installed packages
>> (found by dpkg -l) that you don't want to upgrade to New.deb" or
>> something like that.
And what are you doing with the half-installed packages which "you don't
want to upgrade"? Downgrade? Letting them linger around?
None of those options is a good idea, they are even dangerous.
The only reasonable easy way out of the mess is what the message suggests,
there are other options, but those are better only used by people who know
what they are doing…
The wording ("must") is maybe a bit strong, but given that there is a chance
that your machine is currently in a situation in which it doesn't even boot
I guess its okay that it isn't a "should".
So, in short: What you assume to be a "good chance" is completely outside of
what will be support(ed/able) and hence the message isn't changed to handle
it (also as its unclear what should be the alternative) -> closed.
Best regards
David Kalnischkies
--- End Message ---