On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote:
DPkg::NoTriggers "true";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";
After talking about this bug a few days ago with APT Deities (David
Kalnischkies, in this case), he told me that apt doesn't use "dpkg
--triggers-only" by default.
He believes that apt /could/ issue that command when
"DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
possibly other similar ones (he didn't mention the specifics).
Such options as marked as experimental and dangerous (man apt.conf) so
maybe they are better left disabled unless there's a specific need to
use them.
On the system with the problem, that setting comes from a file named
/etc/apt/apt.conf.d/triggers, whose entire contents are
# cat /etc/apt/apt.conf.d/triggers
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";
It was last modified in 2011. I have no memory of having created this
file, but it doesn't belong to any package either. Searching the 'net
for that combination of options brings me to
https://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and bug #626599. It is probable that I saw Raphael's blog post go by
and decided to try it out.
I have another computer that runs unstable, and which had not yet
received the systemd 229-2 update; I verified that it does *not* have
any of these settings and then ran the update. It went through with
no problems.
So that's a pretty strong indicator that this non-default mode is the
cause of the problem. And it's corroborated by the dpkg/apt logs on
the computer that didn't have these settings, which show no sign of
the problem in the past, as far as I can tell. But just to make sure,
I would like to leave this bug open until another systemd update comes
along and I can confirm that disabling these settings addresses the
problem on the computer that definitely did have it.