Comment 18 for bug 1633520

Revision history for this message
In , Simon McVittie (smcv) wrote :

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

I'm not disputing that - but in that situation, I really don't think it's right to specify a full path that gets rewritten internally to mean something other than what it says.

Hence the various suggestions on the .desktop file thread: paths relative to the .desktop file (or in this case the .service file), or paths relative to the loading executable's $prefix, or paths that start with some magic token. https://lists.freedesktop.org/archives/xdg/2016-June/013754.html explains those options in more detail, and explains why my preferred one of those is relative to the .desktop file.

If this is something that Canonical has a need for, please try to push the .desktop file discussion towards some sort of consensus (which might be as simple as writing detailed pseudocode for what relative paths should mean and justifying why that meaning was chosen), so that we can make relative paths in .service files do the same thing as relative paths in .desktop files. There was at least one Canonical developer (desrt) already involved in the thread I linked.

I'm afraid I don't have the mental bandwidth to reach that consensus myself - other things that I'm working on are more important to me. If reaching that consensus is more important to you than it is to me, please help.

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

To be clear, I consider this resolution of relative paths to be an accident, not a feature: it's a side-effect of how the service-spawning code is implemented. When we reach a consensus on what more useful thing should be meant by relative paths, it will change.