As snapd evolves, so do the interfaces it exposes. Some of them have become obsolete, either because there are better alternatives, or even because they grant access to services which no longer exist – the latter is the case of a few snapd interfaces which were written in 2016/2017 when Canonical was porting Unity8 to the desktop: while the Unity8 project is still alive (now called Lomiri), the exposed APIs have been renamed and changed in such ways that the interfaces currently offered by snapd don’t work anymore. And given that they have almost no users, it seems that this is a good time to officially deprecate them and add a check to the review-tools so that no snaps using these interfaces are uploaded to the store anymore.
thumbnailer-service: service is unmaintained, and no currently published snap is using this at the moment.
Candidates for deprecation
location-control: the location service this interface works with is not shipped in any distribution.
media-hub: not shipped in any distribution; upstream ABI has changed.
online-accounts-service: upstream ABI has changed; might be useful for KDE, but the interface needs to be rewritten anyway.
storage-framework-service: the service was never released.
ubuntu-download-manager: not shipped in any distribution; upstream ABI has changed.
unity8: project abandoned, new one (Lomiri) has incompatible ABI.
unity8-calendar: same as for unity8.
unity8-contacts: same as for unity8.
This post will be updated to show which interfaces have been deprecated and which are in the candidate list. Feel free to comment if you think that some interfaces shouldn’t be deprecated.
we’ve also got a location-observe interface that seems to provide the access to the service location-control allows control of. There are still location services on modern desktops, but they’ll probably go through xdg-desktop-portal. It doesn’t look like there is any static access check similar to the network connectivity portal, so it’s not clear keeping either of these would be worth while as a marker interface.
The accounts-service includes rules to talk to both the GNOME Online Accounts service and the old Ubuntu Online Accounts service. Should the UOA side of this interface be considered deprecated?
Also: would it be possible for snapd itself to tell developers/users when they install a snap that includes deprecated plugs or slots?
initially I was thinking of deprecating location-observe too, because, as you pointed out, it’s written specifically for a backend that we don’t have anymore. But then I thought that any other implementation of a location service will also be made accessible through an interface with that name, so deprecating the interface to resurrect it later with a different implementation doesn’t seem to me better than just rewriting it. Even if we’ll use the XDG desktop portal, I guess we’d still call it location-observe, won’t we?
As for the accounts-service interface, I had a look at it and at its git history, and I believe that that com.ubuntu.OnlineAccounts is just an error, and it was not meant to give access to UOA: there’s just a D-Bus rule about the Introspect method, which IIRC UOA didn’t even implement. I’ll propose a branch to change that into org.gnome.
The similar case is network-status, which was updated here to remove the old Ubuntu Phone connectivity service support (which happened to be broken anyway), and left it mostly as a marker interface:
The NetworkMonitor portal then checks to see if the snap has the interface connected before providing access, mirroring a similar check it does for Flatpak apps.
In the case of the location portal, it doesn’t perform such a static check. Instead, the user is required to explicitly grant location access via an access dialog. So it’s not quite as obvious that a marker interface is needed.
It’s probably not needed for the portals, but it could be needed when an application needs to talk to geoclue, gypsy or gpsd; those are likely to be the preferred interfaces for an IoT device.
This is all nice, but review-tools is outside of the scope Snapraft’s scope; it can stay here but I wouldn’t expect for it to be picked up by its owner
