[Pkg-utopia-maintainers] Bug#804183: dbus fails to start, circular inclusion of *.dpkg-bak

[Simon McVittie]

Control: retitle 804183 downgrading dbus from 1.10.2-1 leads to circular inclusion of s*.conf.dpkg-bak

On Thu, 05 Nov 2015 at 14:40:53 -0600, Brent S. Elmer wrote:
> I had dbus 1.10.0-3 installed on my system then I
> upgraded to 1.10.2-1.  After some series of upgrades, bluetooth stopped working
> so I was reverting packages that I had recently upgraded one of which was dbus.
> So, I downgraded dbus from 1.10.2-1 back down to 1.10.0-3.  After I did this,
> my computer failed to boot.  I was able to boot into recovery mode.

Downgrading packages is officially not a supported action, but this
failure mode is obviously quite bad, so I'm leaving this bug as
release-critical while we work out whether it can be avoided.
Retitling the bug to make it clearer what its scope is.

The session and system buses have identical logic for this stuff, so let's
ignore the session bus and concentrate on the system bus. If there's a
solution for the system bus, then there's a very similar solution
for the session bus too.

Before upgrading to 1.10.2, had you modified /etc/dbus-1/s*.conf?

Please show me anything relevant to dbus from /var/log/dpkg.log* and
/var/log/apt/*, going back to before you first attempted to install
dbus 1.10.2-1? I'm particularly interested in whether the package went
via some unusual state (maybe a failed or partially-failed upgrade)
before you did the problematic downgrade, and in any messages that it
emitted in /var/log/apt/term.log* during the upgrade and downgrade.

> Here is what /etc/dbus-1 looks like:
...
> lrwxrwxrwx 1 root root   29 Nov  5 09:24 system.conf ->
> /usr/share/dbus-1/system.conf
> lrwxrwxrwx 1 root root   29 Nov  3 13:23 system.conf.dpkg-bak ->
> /usr/share/dbus-1/system.conf

This is a step closer to the root cause of the bug: system.conf.dpkg-bak
shouldn't be this symlink into /usr (probably something is wrong in the
maintainer scripts, and that's is causing you to get into this bad
situation). With dbus (>= 1.10.2-1), what you are meant to get is:

    /usr/share/dbus-1/system.conf (a real file)
        upstream's standard bus setup

    /etc/dbus-1/system.conf -> /usr/share/dbus-1/system.conf (a symlink)
        backwards compat symlink so dbus << 1.10 can reload successfully
        after upgrading to >= 1.10 but before rebooting

    /etc/dbus-1/system.conf.dpkg-bak (a real file, if it exists)
        your previous modified bus setup (only if you previously modified
        system.conf, even though it contains comments telling you to create
        system-local.conf instead)

> So, I don't know what the intent was with including the dpkg-bak in the two
> ..conf files but it causes severe breakage.

The intention is that as required by Debian Policy, modified configuration
files are kept (even though in this case you're meant to create a parallel
file instead of editing them). The bug here is that the compatibility
symlink gets treated as though it was a modified configuration file - it
shouldn't be.

The sequence of events in your downgrade, ignoring recovery paths if a step
fails, goes something like this:

* 1.10.2-1's prerm with arguments "upgrade 1.10.0-3"
** dpkg-maintscript-helper rm_conffile /etc/dbus-1/system.conf 1.10.0-4~ dbus -- upgrade 1.10.0-3
* 1.10.0-3's preinst with arguments "upgrade 1.10.2-1"
* unpack files from 1.10.0-3
* 1.10.2-1's postrm with arguments "upgrade 1.10.0-3"
** dpkg-maintscript-helper rm_conffile /etc/dbus-1/system.conf 1.10.0-4~ dbus -- upgrade 1.10.0-3
* remove any files from 1.10.2-1 not present in 1.10.0-3
* file list from 1.10.0-3 becomes active
* 1.10.0-3's postinst with arguments "configure 1.10.2-1"

(reference:
<https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact>)

    S