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

[Allison Lortie]

hi Simon,

Thanks for writing all of this up.

I have only one concern below (and it's sort of a hand-wavy thing that
I'd appreciate more feedback on).

On Mon, Jun 20, 2016, at 13:24, Simon McVittie wrote:
> One subtlety of the phrasing is that a single .desktop or .service file
> might be visible in more than one directory thanks to symlinks, hard
> links or bind mounts. Thiago's phrasing makes it specific that it is the
> directory that actually appeared in the .desktop or .service search path
> that matters, and not any of the same file's other apparent locations.

It must be this way, at least for hardlinks, since there is no way to
tell which one is the "real" one.  I don't think we should be speaking
about search paths, though, because it may confuse the issue.  What
happens, for example, if my homedir contains a symlink to a desktop file
in /usr/share/applications?  Reading "search path" here makes me think
that maybe I need to be more intelligent about how I treat this: do you
really intend for me to check if the destination of the symlink is in
one of the standard directories and proceed accordingly?  This is a
no-go.

On the other hand, what we are doing here very much might break the
previously working behaviour of making symlinks from
/usr/share/applications into the user's home directory.  We might
imagine that a user has a collection of their favourite apps in some
folder on their desktop, and an app changes to a relative path scheme in
their Exec= line on an upgrade, breaking the user.  That was not
possible before, but with this change, we make it possible, so in a
sense, this could be viewed as a break.

On the other other hand, if we follow this all the way down the rabbit
hole, we may get into weird situations whereby we're canonicalising
symlinks in situations where /usr is a symlink to /mnt/usr or something
equally awful, in which case we might end up at the wrong result.  For
that reason, I think we should limit any resolution step here to direct
inspection of the desktop file in question for being a symlink, itself,
and not attempt a full canonicalisation.

tl;dr: for ease of implementation I lean toward "do the dumb thing" and
for user-friendly I lean toward "do the hard thing".  Overall, I think
we should do the 'hard' thing, mostly because we only have to pay the
extra cost of the path canonicalisation in case we find a relative path
on the Exec= line.  In any case, I do not support any reference to or
mention of "search path".

> For the somewhat obscure feature in which
> ".../applications/foo/whatever.desktop" is equivalent to
> ".../applications/foo-whatever.desktop", I don't really care whether the
> relative path is relative to .../applications or .../applications/foo. I
> would go for .../applications if I have to make an arbitrary decision,
> but I believe this feature was added to support something in KDE, so
> I'll defer to whichever one KDE developers would prefer.

I strongly suggest that this case is resolved relative to the directory
in which we found the actual file.  It should always be possible to find
a bare desktop file in a random directory and run it directly, without
having to guess that this directory may be a subpath of the search path.

Thanks again for the excellent write-up.

Allison