Update snapcraft.yaml

[eugeneseppel]

snapcraft.yaml is updated to make possible snapcraft build on Ubuntu 20.04 LTS
In scope of this PR:

• added the required dependency libasound2,
• base core specified explicitly as it is needed for the current snapcraft,
• service (daemon) is removed from snap. I think that running this daemon under superuser account (even in a confined snap) is not a best option from the security perspective. Also different PC users may require different Spotify premium credentials (like family members with different music taste) and the best place to store the credentials is user's profile or keychain, but single spotifyd system instance can't use every user's keychain with the default configuration. So the current approach of running spotifyd as a system-wide service is insecure, non-manageable and not suitable for everyone. Hereby it's better to leave such configuration on user's responsibility than introduce the insecure approach.

[eugeneseppel]

Original problem with "." source (source folder was not populated to the build VM) was because of the source folder location

[eugeneseppel]

Could please someone else also approve this? 2 approvals are needed.
Thank you!

[eladyn]

LGTM! Regarding the third change, I do have some questions:

service (daemon) is removed from snap. I think that running this daemon under superuser account (even in a confined snap) is not a best option from the security perspective.

This documentation suggests to me that spotifyd isn't actually run with root, so this shouldn't be a problem security-wise?

Also different PC users may require different Spotify premium credentials (like family members with different music taste) and the best place to store the credentials is user's profile or keychain, but single spotifyd system instance can't use every user's keychain with the default configuration. So the current approach of running spotifyd as a system-wide service is insecure, non-manageable and not suitable for everyone. Hereby it's better to leave such configuration on user's responsibility than introduce the insecure approach.

I'm not at all familiar with snaps, but I think I understand your reasoning here. Unfortunately, a daemon-scope: user feature, which – it seems – would fit perfectly in this situation, still hasn't made it out of the experimental phase.

Is there a way that users can execute a snap command directly, even if it is installed as a system service. The reason I'm asking is that I would suspect that most people using the snap rely on it being available as a system daemon, so changing that would break their setup, right?

[slondr]

Closed as we no longer officially support snap