Hello sweeties! Last week Scarlett, Aleix, Matthias and I took to the Snappy sprint in Heidelberg to discuss how to make it the most useful for KDE. I'd like to give you an overview of what was discussed along with some background, so we are all on the same page.
If you already know what Snappy is, you can skip the next paragraph. Snappy is one of them fancy new bundle packages: AppImage, Flatpak, Snappy. Out of those three Flatpak and Snappy are based on Linux Containers/CGroups/Namespace and that whole slew of magic. Simply put they are like docker. AppImage is not using this but seeks to have self-exectuable self-containing LD_LIBRARY_PATH'd programs. Snappy for the most part is 3 things: - a store REST API (of which the reference version is the ubuntu store) - a daemon on the system (snapd, imagine it like dockerd) - a .snap file containing the installed tree of an application (including deps, although that's going to change soon) Generally speaking the store bit isn't technically necessary, it is the primary means of distribution right now though. Shipping things users can use on Linux has been a pain in the rear since forever and these bundles are meant to change that. As such we as KDE should have a strong interest and presence in this field in the hopes of shaping a future that is useful to us. After all, we are one of the biggest source distributors, and the primary reason we don't also offer generic binary packages of our applications is because this never scaled and was altogether terrible to pull off from a KDE point of view. Unfortunately right now we are in a state of limbo with regards to bundles. Everything sort of makes sense but none of them allows us to do large scale building and shipping to users. Which means we need to spread our resources a bit to get good coverage for everything. Not spreading ourselves too thin certainly is a key concern though. With all that in mind, let's take a look at snappy. I think it is best if I don't get into too much detail of how exactly snaps are built or run, but the gist of it is that snaps get "packaged" from highlevel definitions describing what we expect to happen (e.g. cmake should run and then we should have usr/bin/kitten and put that in our snap). If you have seen how Flatpak does it... describing snaps looks very similar. Using fancy kernel tech the snaps at runtime then get isolated from the rest of the (userspace) system allowing them to be fully compatible with any base distribution (in theory anyway). Snappy right now has limited exposure as it is only available on Ubuntu (Unity). This is actively being worked on with main blockers being missing golang stacks (snapd is mostly written in Go), missing apparmor patches (pending upstreaming), and systems that don't use apparmor at all which I guess is the biggest hurdle (needs special kernel configurations). Overall there seems to be interest in having things work well everywhere, which is good of course. Additionally, there's also cool stuff in the works such as adding snap build support in the open build service (OBS). Snaps are generally built on a minimal ubuntu 16.04 core, which is the base they then also get run against. Technically I guess that isn't forced though (same as with Flatpak any old base could be used). This gives us an ever so sweet advantage with Snappy. We already have KDE neon which is based on Ubuntu 16.04! So, Scarlett and I built some high level mass automation of snap building on top of neon's existing deb binaries. Today we have most of the kf5 apps we have in neon also built as snaps for testing purposes. Not all of them work of course, but it's a start. And having them based off of the builds neon does anyway means they are dirt cheap in both developer and build time. Short-term this allows us to test and polish snaps. They are fairly large but that is more because of present snappy deficiencies than anything else (bound to be fixable very very soon). Mid-term I think we should get to a point where we have most of our KDE Applications available as high quality snaps and push them to the Ubuntu store. This store should eventually one supposes be exposed through the software center in Ubuntu (I am sure we can get something ironed out to get discover in Kubuntu also to support it somehow). This will probably require some policy discussion to make sure we only release highest quality snaps as we then have direct end-user exposure. But more on this at later time. The long-term target of course is to not have to base off of debs at all. A key component of this should become available soon in the form of what Snappy calls "content sharing". It's basically a way for us to have a "KF5" snap which gets shared by all apps that wish to use it. A shared library bundle, if you will. This will allow us to cheaply build applications via snappy's build tech and entirely bypass .debs. And also minimize the size of individual application snaps. Also right now building snaps is a fairly centralized thing, which would be hard for us to scale in say Jenkins, so we are hoping for improvements there. If snaps become a worthwhile persistent investment for us we'll want to make it as easy as possible for devs to spins snaps. This is also a point of view shared by the snappy team: the dev experience should be as awesome as can be. So, where does that leave KDE? Pieces are moving all over the place and being able to not commit to one format right now is a handy advantage. As such I think from a neon point of view we'll continue to do cheap snaps, and make sure to get them to release quality soon. And be it only to get a foot in the door, as it were. I certainly want to try to build a more efficient and streamlined experience once we have the content-sharing to play with at which point we might also want to look into best practices if application authors want to take direct control, which I think is what we should target in the long run. All the stuff we did and will do in the near future is non-committal. And it is important that we keep it that way for now. I looked a bit into all the bundle tech on the table and I don't find any of them compellingly advantageous right now. What we need to do is make sure to poke things, see how they work for us, complain and make our voice heard. So, keeping an open mind is important to end up with a future that is right for KDE. Whether or not that is going to be snaps, I can't say. I certainly get the feeling that the team behind the tech is very excited and committed to giving us the ability to get our software to all the people in the best way possible. I'd absolutely love to hear everyone's opinions, fears, hopes, questions for snaps and application bundles in general. If you want to discuss snapping your application or have general questions/input/whatever on the automation code we have in place right now poke me on IRC or elsewhere. Cheers, HS
