which desktop ? … dont forget … snaps run on fedora, opensuse, solus, debian, arch, mageia, mint, ubuntu etc etc …
We’ve not codified when to add policy-- each is examined on a case by case basis. In this case it was clear that your snap should be able to look at sensors3.conf if it exists because that is what the user would have configured (and if other distros used a different name for the file, we would add it). If /etc/sensors3.conf didn’t exist, your snap could choose to provide sensors-detect to write out a configuration to SNAP_COMMON (or similar) and your snap could use that instead.
It’s a judgement call. For an implicit core interface (ie, it only exists on Ubuntu Core and not classic distro) then we are quite strict that the resource needs to be provided by the core snap (even with that said, the core snap will be slightly different between amd64 and armhf (eg, grub vs uboot) so we might say ‘needs to be provided by some core snap’). With implicit classic interfaces (ie, those on a traditional deb/rpm based distro) we will ask whether it is commonly present in the distro (eg, udisks) and leave it up to the snap to deal with when it isn’t. We’ve been starting to be a little dynamic with that where we check what distro we are running on (eg, recently the calendar-service (evolution data server) is not available on 14.04 cause it is too old), but we don’t yet have a strong concept of dynamic slots yet, so we can’t say, check if udisks is installed and only then expose the slot. This is dynamism is coming and perhaps we can expose interfaces for services in this manner. Currently this exposes a rough edge in snapd where say, password-manager-service is an implicit classic slot, but on server secret-service is not installed. In practice this is not a huge deal because people understand that a server doesn’t provide the desktop environment required by the chromium snap (which uses password-manager-service). With the aforementioned dynamism, we can improve this.
Some things are very clear though-- if a library, file, executable, etc is not in a default install in a typical distro everywhere (eg, adb, java, etc) then the snap needs to ship it and if a snap wants to be sure it works on atypical distros, it should ship the file.
It is possible. Please create a new topic and follow Process for aliases, auto-connections and tracks
Thanks for the detailed explanation - definitely sounds like the dynamic stuff will be a good win and the general policy makes sense.