Comment 16 for bug 1633520

(In reply to Michael Terry from comment #4)
> 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.

I am really not comfortable with rewriting absolute paths to mean something that isn't actually what they say - I feel as though an absolute path should lead to "you asked for it, you got it", with anything else being a violation of the least-astonishment principle. I wasn't a D-Bus maintainer at the time the Windows install-prefix-rewriting was implemented, so I've tolerated what we already had; but I'm not a fan of it extending its tentacles outside the Windows special case, and I'd like to be able to replace it with something less astonishing.

We have had efforts in the past to make D-Bus .service files relocatable in a less astonishing way, by interpreting *relative* Exec paths (which currently have no useful meaning) as relative to something (the original suggestion was dbus-daemon's $prefix, but "where I found the service file" seems better). However, I think it would also be a least-astonishment problem if a relative Exec didn't mean the same thing as it does in .desktop files, its meaning is currently undefined in .desktop files, and when I raised the equivalent question for .desktop files the conversation descended into disagreements about how the relative path should be resolved in corner cases (if you symlink a desktop file between directories, or worse, copy/symlink it to your ~/Desktop and double-click on it).

Relative paths in .desktop files also seem like something you will need for this current effort in Snap; it would be helpful to try to get some sort of consensus there. Latest attempt: <https://lists.freedesktop.org/archives/xdg/2016-June/013754.html>

I am not a huge fan of Snap's approach to relocation in general: the way Flatpak does this, with userns + bind mounts so the path really exists at least in the container's view of the filesystem, seems a lot more honest to me.