Comment 17 for bug 1633520

> I am really not comfortable with rewriting absolute paths to mean something that isn't actually what they say

I'm sympathetic to that position. But

A) A data file like a dbus service file simply cannot specify a full path, if its proper path is only known at run time. Which is the case for snaps, and maybe other use cases too(?).

B) In some cases, the administrator knows more about how they've set up the environment than the service author *can* know. The administrator can edit the file, sure. But an environment variable is often an easier approach for them (at least if all the administrator has done is moved its root).

For the work I'm doing, I can hack my snap to use relative paths in its bundled dbus service files (chop off their '/' prefix) and run dbus-daemon --session with a cwd of the snap root directory. That would let me use dbus's existing relative-dir support in my favor. For as long as dbus still supports that way, at least.

So I can hack it. But I was hoping for a cleaner way of doing that in a systematic way (and maybe help people doing similar things that don't have the luxury of being able to do the hack I can).

> ... with anything else being a violation of the least-astonishment principle.

I understand that what the Windows side is doing may be a bit surprising. Since that check is always on.

But with this patch, the relocation support is opt-in by setting DBUS_ROOT. In which case, the relocation would be quite expected. Maybe it would be even less likely to surprise if it was a command line argument?

> Relative paths in .desktop files also seem like something you will need

I don't *think* I'll actually need that. I'm snapping unity8, and for .desktop based application launches, it has code to prefix the correct root directory onto the Exec line (since it reads those and knows when it's running as a snap).