Snappy sprint reporty musing

[Harald Sitter]

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