Relative paths in .desktop, .service files' Exec= lines

[Simon McVittie]

On 23/06/16 19:28, Jasper St. Pierre wrote:
> Uh, so this might be a dumb question, but how do relative paths help
> relocatability?

Install foobar into --prefix=/opt/stuff; add /opt/stuff/share to
XDG_DATA_DIRS (or otherwise arrange for your desktop environment to
search /opt/stuff/share/applications); now if
/opt/stuff/share/applications/foobar.desktop says Exec=../../bin/foobar,
launching it will start /opt/stuff/bin/foobar.

The same applies to share/dbus-1/services, with an extra level of "../"
to compensate for the extra level of nesting.

(D-Bus on Windows actually replaces its own compile-time $prefix at
runtime with wherever it has discovered it is actually installed, for
example if you used --prefix=/mingw but installed it in C:\mingw32, it
will look for service files in C:\mingw32/share/dbus-1/services, and
interpret Exec=/mingw/bin/foobar as if it said C:\mingw32\bin/foobar -
but I think that's really weird, and I don't advocate it for use on Unix.)

> Doesn't resolving paths relative to the .desktop file mean that it is
> intricately linked to the filesystem layout?

The *relative* filesystem layout, yes, but the tree as a whole is
relocatable.

> This would break something like Alacarte, which, when you might want
> to put an icon in another folder, copies it into
> ~/.local/share/applications.

Hmm, that's a good point; perhaps this is more generically useful for
D-Bus .service files than it is for .desktop files. I was really hoping
I could get the same syntax specified for both rather than randomly
diverging, though.

> This doesn't seem to help flatpak, which would have the .desktop file
> hardlinked into the user's system at /usr/share/applications

Actually /var/lib/flatpak/exports, but flatpak has to rewrite the
.desktop file to have "Exec=flatpak run ..." anyway, so this isn't an
extra burden for Flatpak.

AIUI it's useful for Snap, which installs into arbitrary prefixes (and
currently compensates by setting a massive number of environment
variables), and possibly for AppImage, which mounts itself as a
filesystem at an arbitrary prefix.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>