The Linux world has always worked with a develop and deploy model where software gets written by projects such as KDE and then distro projects pick that up, polish it and give it to the user. No other computer environment works like this and it goes against the fashion of DevOps concepts where the people who code are empowered to deploy to the end user going through QA as appropriate. We changed that with KDE neon where we brought the packaging into KDE making .deb packages. That integration allows for blockages and imperfections which get identified to be solved easily through the most efficient channels. Kipi Plugins is a good example of this, KDE dropped the ball here by stopping releases. Nobody noticed until as a packager I wondered where it had gone, realised it was no longer being released and, because I work directly in the project responsible, could easily fix that in the right place. With new containerised formats Linux is changing, and projects like KDE can now package software and send it direct to the user. I’ll discuss this more in a future blog post but for now lets look at Snaps where last week, for the first time, KDE Applications was released with 50-odd apps available directly for all to enjoy direct from the Snap Store.
Give it a Try
First you need to install snapd which comes as default with KDE neon and Ubuntu distros but others will probably need to enable it manually. See the Snap set up guide.
For Plasma Discover integration you should also install the Plasma Discover backend snap package, it is called ‘plasma-discover-backend-snap’ in Debian/Ubuntu/neon but the naming convention in your distro may vary.
You can now install Snap packages directly from the store which uses snap:// URLs to start Discover and install them. You can also install snaps from the command line.
If you look at the KDE page on the Snap Store you can see the 50+ packages we have available today. Most of the packages are fairly simple apps such as games and education apps, future work is to do many more KDE apps.
Snap Store? Channels? Who controls this?
Snaps follow a similar model to other large providers like Android, iPhone, Windows, Steam, etc with a centralised store, in this case run by our friends at Canonical.
There is a KDE publisher account on the Snap Store which is currently controlled by your friendly KDE neon team. Anyone can make their own publisher account, and there’s a nifty feature to mark it as a collaboration between several accounts. For example Kdenlive is made by the Kdenlive Jean-Baptiste but the KDE account also has access.
The Snap Store features channels intended for software in different stages of their development cycle, this mirrors quite closely what we do in KDE neon for our .deb archives. Most users will only care about the Stable channel offering thoroughly tested software.
There is also the Candidate channel for testing builds of released software. The Edge channel is for Git master builds same as Unstable in KDE neon and the Beta channel is for Git beta branch builds same as Beta edition in neon. By default Snap will only install stuff from Stable and you have to ask explicitly for other channels but this is a great way to be testing pre-release software.
When uploading to the Snap Store for the first time there is a manual review package by archive admins which is similar to uploading new stuff to Ubuntu or many other distros, you also need manual review when you first upload a Snap package which asks for special permissions such as talking to DBus. The reviewers are nice people inside Canonical who you can ping on the Snap forums if you need to.
You might notice the KDE publisher page on the Snap store is missing a load of icons and other met data such as screenshots. These should come from AppStream files but AppStream support is still working its way into the Store backend and build tool snapcraft so not all the icons are there yet. It seems we need to work out how to use a newer snapcraft on KDE neon servers to get all these magic features sorted.
Snapd runs on your system and takes care of downloading and installing the packages. It will update Snap packages automatically so you can be confident you’ve got the latest and greatest provided by the publisher.
How’s it Built?
Snap packages are built with a snapcraft.yaml file to define how and what needs to be built by a tool called snapcraft.
In KDE neon, we have a load of Git repos for our .deb packagingm and we have reused these for our Snap packages. The neon repos are documented on the KDE wiki, and asa KDE project, all KDE dev account holders have full access. For example, KAtomic has a snapcraft.yaml file , a metadata icon and .desktop file.
Here at KDE neon tower, we have a team of guinea pigs building our .deb packages. , We have repurposed the same guinea pigs to build these snap packages. , The build jobs get created on KDE neon Jenkins servers and when someone triggers them (any KDE dev has access), the build is made on the floating cloud of guinea pigs. If successful, it is uploaded to the Snap Store.
This is nice, but is still not as integrated as it should be. Newly released sources are built and uploaded to the Candidate channel on the Snap Store, which then needs manual review before moving to the Stable channel. Thist should get automated using openQA.
And there’s not really any need for any of it to reside on the KDE neon servers, everything should be even more tightly integrated with the rest of KDE and built as part of the new invent.kde.org CI system, and then uploaded from there. It shouldn’t be the responsibility of KDE neon team to make these, it should be done as part of the app development process. So jump on board and enter a new world for empowered, rapidly released software!
To find out more about the Snap format follow the tutorials, read the docs and browse the notes on KDE paticular stuff.
