Neon/Snap

Usage

To use them

https://apachelog.wordpress.com/2017/01/30/kde-applications-in-ubuntu-snap-store/

sudo snap install kde-frameworks-5
sudo snap install kblocks

ISOs from August 11 2017 already come shipped with kde-frameworks-5, this is a simple tar made by Jonathan by using a freshly installed virtual machine, running sudo snap install kde-frameworks-5 and putting /snap, /var/lib/snap and /var/snap into a tar http://embra.edinburghlinux.co.uk/~jr/snapd-kde-frameworks.tar.gz It adds about 600MB to the images.

No sudo

To drop the requirement to have to sudo everything you need to login using ubuntu login credentials first.

sudo snap login

After that you should have a ~/.snap/auth.json file and snap should work without sudo.

Problems

(upstream issues ought to be filed/subscribed to and mentioned here)

1. Content snap not getting installed if snap depending on it gets installed https://bugs.launchpad.net/snapcraft/+bug/1711329
2. Installing a content snap into the core ISO requires snapd which requires systemd which cannot (?) run in a docker/lxc/chroot
   1. current solution is to tar up /snap etc and extract that when generating the ISO.
   2. This needs the tar to be easy/automatically updated
   3. Needs openQA tests that it still works
3. Theming
   1. How to get theme settings from the host into the snap?
   2. QtStyles are binary plugins and so even when we know which style is configured on the host we cannot just load it
   3. Icon themes in /usr/share and ~/.local cannot be accessed from inside snaps
   4. Same for mouse cursor themes
   5. Same for fonts
4. There are no debug snaps making debugging of crashes nigh impossible. Possibly needs a way to catch and send cores and then retrace them server-side with (externally) generated debug symbol dumps?
5. xdg-desktop-portals (with patches) + snapd (with patches). Needs landing or something
   1. FIleIO
   2. Printing
6. No real way to run unit tests through snapcraft (do we need to?)
7. Content snap has "external" dev tarball which we utilize to build snaps off of the content snap, problem is that snapcraft does not like files diverging, so whenever a snap stages-packages something that is in the dev tarball (e.g. as part of a runtime dep) but binary different (e.g. newer build) the snapcraft will fail. On auto generated snaps this was worked around by maintaining an exclusion list of packages to not install, this may be auto-injectable into manual builds BUT won't be doable for non-infrastructure builds (i.e. a dev running snapcraft on their system).
8. Discover integration experimental still
9. snapcraft does not work on archlinux/fedora (says Aleix)
10. Content snap makes development super hard! A locally installed snap cannot connect to the content snap if it was installed from the store, conversely, a locally installed content snap cannot be used by snaps installed from the store. So, either everything needs to be installed locally or through the store, the store round trip makes development of new snaps a right chore and lengthens the feedback cycle considerably. Possible workarounds include maintaining fully-standalone snapcraft.yaml files and having the CI tooling mangle it to base it on the content snap for store uploads.
11. Substantial metadata duplication. snap metadata excessively duplicates appstream metadata such as license, summary, version, icon. Makes it undesirable to maintain the data in snapcraft.yaml so it will simply go out of date at some point.
12. No source code storage/retrieval for snaps https://bugs.launchpad.net/snapcraft/+bug/1711333
13. Excessive data duplication for the setup/gui/ directories. As snapcraft has no ability to pull desktop files and/or icons out of the stage itself one needs to manually keep copies of the relevant artifacts in the setup/gui/ directory for snapcraft to pick them up. This is extremly meh and unsustanable without extra code that grabs and updates the desktop file from somewhere as the file contains translations which change/grow all the time.
14. Icons do not appear to get installed into hicolor nor hardcoded absolute paths in the desktop files, making icon availability entirely theme-dependent.