pending publisher vetting for the use of shutdown, +1 (#voteFor) from me for auto-connecting these interfaces as this is expected functionality for the snapped application.
Given that it is an unofficial snap and Kodi core functionality would still work without these interfaces, I’m more inclined for the manual connection.
My suggestion would be to use a wrapper script to launch Kodi. In this wrapper script you can use snapctl is-connected to check whether these interfaces are connected or not:
if shutdown is not connected: inform the user that restart, shutdown and sleep functionality won’t be available and explain how to connect the interface
if dvb is not connected AND there are valid dvb devices connected to the system (/dev/dvb/*) explain the user how to connect the interface)
No, it does not sound reasonable. Kodi is a media center. The user’s use case ranges from DVB usage to DVD drives, USB sticks, and more.
With 115 votes and mostly poor rating in the Snap Store, I therefore think that most users just want to install the snap without having to worry about anything. A wrapper script is additional effort, and I don’t have time for that. Additionally, a wrapper script is also unfamiliar to users. Most of them probably don’t know what they would actually need to enable in order for Kodi to run the way they need it to. I raised this question here because it was asked about in a Kodi forum. In addition, there was a similar bug report on GitHub
Additionally, I cannot add the shutdown plug without it being approved in the Snap Store. Apart from that, the Kodi developers have a rather negative attitude towards snaps and instead focus on Flatpak. And Flatpak - Kodi runs really poorly : GitHub · Where software is built
for dvb you can try to convince reviewers that it is required for kodi core functionality and the snap makes no sense without this interface.
for shutdown I don’t think we can do much else. It is a super privileged interface and, as such, it requires snap/publisher vetting. Part of the vetting is checking that the snap is published by the upstream project, which is not the case. The usual recommendations are either to ask the upstream to adopt and maintain the snap themselves or ask the snap publisher to join the upstream project when possible.
A wrapper script is additional effort, and I don’t have time for that.
That sounds a bit concerning to me already. If you don’t have time now, how do you plan to maintain the snap? Even if you don’t plan to follow upstream, how do you plan to do the periodic rebuilds required to bring security updates?
As mentioned, nothing will come from the upstream project; they have a negative opinion of Snap.
The inability to shut down Kodi from my snap happens only on Ubuntu Systems. When I test the latest Snap build in the store on OpenSUSE Leap, Debian, etc., I can shut down the computer using the current Kodi settings.
I built Kodi as a Snap because the Kodi team no longer creates deb packages and the provided Flatpak package doesn’t work properly. I use it myself on an Intel HDMI stick, so I have a personal interest in making sure the Snap build works ;-).
I don’t want a separate launcher script for various reasons. However, I uploaded two simple Bash script here to manage snap permissions :
With it, it is possible to change Snap permissions either in the terminal or using Zenity.
I want to include that in the description.
The inability to shut down Kodi from my snap happens only on Ubuntu Systems.
The shutdown control (whether it is allowed or not) relies on Apparmor being installed in the host. That might be the reason.
I don’t want a separate launcher script for various reasons.
Actually it does not need to be a separate launcher, you can do it using the snap command-chain[1,2] functionality. It would allow you inform the user about what functionality would be missing without the interfaces (only if the interfaces are not already connected) and how to manually connect them the first time the app is started (or every time if you/the user prefer).
