<div dir="ltr"><div><div><div>Hi Simon,<br><br></div>I've been following this list for only a few weeks, so all this is rather new to me (as was the surprise realisation, a little while back, that relative paths weren't already supported!), but I would appreciate some clarification with this relative paths proposal. I agree that support for relative paths would be very, very, nice to have.<br><br>> One subtlety of the phrasing is that a single .desktop or .service file<br>> might be visible in more than one directory thanks to symlinks, hard<br>> links or bind mounts. Thiago's phrasing makes it specific that it is the<br>> directory that actually appeared in the .desktop or .service search path<br>> that matters, and not any of the same file's other apparent locations.<br><br>What is the specific behaviour being proposed here. i.e. how might you determine which path 'matters' without sacrificing some of the convenient relocatability that relative paths provide?<br><br></div>To me it would seem that the most sensible approach for dealing with symbolic links would be to first determine that they *are* symbolic links and follow them to the actual file they point to, then parse in the context of that physical file. That way the .desktop file and all  symlinks (created by the user, or otherwise) would be guaranteed to work with identical behaviour. Doing things like hard links or bind-mounts of .desktop files wouldn't work with this approach, but in practical terms would that actually be a problem? I'm not convinced that anyone in their right mind would bind-mount a single .desktop file in isolation without the context of its target directory structure and expect it to work anyway.<br><br></div><div>Thanks,<br></div><div>Daniel<br><br>________________<br></div><div>Daniel Kos<br></div><div>General Development Systems<br></div><br></div>