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. zw