Comment 5 for bug 1639952

So there are a few interesting things going on here. Some things to keep in mind. The FD.o spec doesn't allow for expansion of variables in the Icon entry. We can't let snaps reference items outside of their own snap directory or it is a security issue (someone can mimic another app, which they could do, but it's worse if they do it locally)

To that end UAL resolves absolute paths in the Icon field as being relative to the snap directory. In essence that means "/foo/bar.png" resolves to (effectively, not literally) "${SNAP}/foo/bar.png". It also means that we resolve "foo/bar.png" to (effectively) "${SNAP}/foo/bar.png". Which is a form that makes more sense.

The problem is that snapd was broken on Unity7 so everyone encoded their Icon paths like they were running on a Ubuntu based Deb system, they put in paths that would only work there (for instance, snapd on other Linux distros uses different paths) because Unity7 didn't do this substitution. Now snapd is making illegal desktop files to compensate and work around that.

The plan to solve this problem is that snapcraft will be setting the icons and the paths for applications so that they are properly relative to the snap directory. This will allow application developers to have predictable results on a variety of distros and icons to work properly on Unity8. Unfortunately we have a set of apps that are broken today.