Re: Bug#776063: dbus fails to upgrade rendering entire apt unusable
Control: reassign 776063 apt
Control: severity 771428 critical
Control: forcemerge 771428 776063
Control: affects 771428 dbus
On Fri, 23 Jan 2015 at 19:04:33 +0100, Guillem Jover wrote:
> I think this one should be merged with the other dbus+triggers+apt
> bugs.
Merging it, using the higher of the two severity values. apt
maintainers and/or the release team are of course welcome to downgrade
it as desired, I'm not trying to play severity inflation games here;
but it seems to be coming up somewhat frequently and it isn't obvious
how to recover, so RC severity does not seem disproportionate.
I notice that before the failing upgrade, Yaroslav had dpkg 1.17.21 and
apt 1.0.9.4 (if I'm reading the right status-file backup), which means
he did not have the fix for https://bugs.debian.org/769609 in apt.
dpkg and apt were upgraded to 1.17.23 and 1.0.9.6 earlier in the same
batch that failed with this dbus trigger thing, which I assume means
dbus was upgraded with the old apt (although maybe the new dpkg).
Is the fix for https://bugs.debian.org/769609 expected to fix this
particular issue, or am I misreading it?
> I don't think this can be worked around in dbus, barring the removal
> of its triggers.
If it's absolutely necessary, I might be able to back out the trigger
for jessie, because it is *meant* to be non-essential: dbus-daemon is meant
to use inotify to monitor the system services directory, and that feature
works fine for me. However, I've had reports that it doesn't work for
everyone, hence the trigger (and in any case it seems more
predictable/deterministic to use a trigger to kick off the reload
when all new packages are known to be fully in place).
Or if dropping it down to interest-noawait would help, that isn't
really semantically correct, but it's probably acceptable in practice?
<https://bugs.debian.org/740139> is the bug report that prompted me to
add the trigger, FWIW.
S
Reply to: