Comment 15 for bug 1633520

Thank you for looking at this!

> Please don't rush into this.

Agreed. I wanted to check with you folks before I actually did anything on the Ubuntu side.

> What is your use case for relocating the system bus?

I don't have one. I was just trying to be consistent with the other changes. I'm happy to drop those bits.

> I'm somewhat sceptical about the correctness of a Snap app-container running its own dbus-daemon - a contained app doesn't sound a lot like a login session to me

In most cases, yes, that wouldn't be a normal thing to do. But this is a bit of a special "fat" snap for an entire desktop environment (unity8 is what I'm testing now, but I don't see why one couldn't also snap up a GNOME or KDE session).

> We implement <standard_session_servicedirs/> by behaving as though our compile-time @DATADIR@ had been appended to XDG_DATA_DIRS; the same would make sense for ${datadir}/dbus-1/session.conf.

So the serviceconf-discovery aspects of my patch were merely me trying to make the Unix side of things be consistent with what the Windows side of things does, now that _dbus_replace_install_prefix was no longer a no-op.

But adjusting XDG_DATA_DIRS is enough for my purposes there. My major goal with this patch was actually to make relocating of activated services work. I think I buried that lede.

In activation.c, _dbus_replace_install_prefix is called on the Exec= line found in the service desktop file.

Consider this snap I'm trying to make, with session dbus and installed session services. One such service might have an Exec line like Exec=/usr/bin/foo-bar. When DBus wants to activate that service, it needs to adjust that Exec line based on where my snap is installed, which is only known at run time. And that's where setting DBUS_ROOT would come in for me.

So my patch to _dbus_replace_install_prefix is what really interests me and I can take or leave my other changes.

Would a patch to just that function be better received, and leave the config-file searching functions alone?