Playing Around With Ubuntu's Snaps, On Fedora

I had a bit of a surprise waiting for me as I walked out of lunch today: Ubuntu's snapper packaging utility had accepted the necessary patches to work on non-Ubuntu distros. The list of supported distributions now includes Arch, Gentoo, Debian, and Fedora.

Setup & Install

My first thought was that I would have to pull the snapper/snap source from GitHub and get compiling. A task that I was not looking forward to, given that it would be my first attempting at compiling a program written in Google's Go programming language.

Thankfully, this was not the case. Snapcraft.io has been updated to reflect the newly supported distributions. For Fedora users, I took a screenshot of the installation instructions.

The instructions are not -quite- complete though. Yes, running snaps do require disabling SELinux-- something that I hope does not remain true in the future-- but it can be temporarily turned off via ‘sudo setenforce 0', rather than permanently disabling it via the config file.

Additionally, I hit the first Ubuntu-ism: the instructions do not acknowledge that you must start the snapd service file after install. In traditional Debian fashion, it is assumed that the service file will be automatically enabled by the package manager, something does not hold true for... any non-Debian based distribution, to my knowledge.

Enabling the service file can be done graphically, or by issuing the command: sudo systemctl enable –now snapd.service.

Snapper's website gives rough instructions on how to find applications from the snap store. Searches are done via: snap find ____; installations are done via: snap install ____; and removals are: snap remove ____. Interestingly, the documentation never mentions root privileges, but attempting "snap install" without "sudo" would fail with permissions issues. This may be because I did not sign into the snap store, as the documentation suggests I do. Regardless though, executing "sudo snap install" worked fine, signed in or not.

Testing Applications

So I've got a brand new package manager installed on my system, but that doesn't do me much good without packages to install right? Executing "snap find *" returned a... less than impressive list. In total there were 7 snaps available from the store for install-- 2 of which were example applications provided by Ubuntu.

Now, to be fair to Canonical and Snapper... The idea behind Snapper is that of OS X (now MacOS) bundles. You don't download them from a central repository, you download them from the application authors directly.

Before testing out a large, fairly complex, application, I decided to test some of the little guys first. Specifically htop, Ubuntu Clock, and Ubuntu Calculator. On the bright side, they "just worked". Once installed, the applications were search-able and view-able in Gnome Shell's application overview, they would execute correctly when ran. Running them from terminal though, and viewing their debugging output, I wasn't so sure though. Below is the debugging output for Ubuntu Clock, notice the "out of memory" error, and the dbus errors.

When one issues "sudo snap install" on an application, part of the downloading output is the total size of the snap. Since snap uses bundled libraries, I was rather curious to see how big these relatively simple applications would be:

Ubuntu Clock App: 120.11 MB – admittedly, this is written in QML, so it has to pull in Qt. Ubuntu Calc App: 120.01 MB – same as above. Htop: 228KB – This one was about in line with the Fedora-native RPM package. Dnf reported an install-size of 224 KB. LibreOffice*... 1.1 GB

That last one was my "complex application" test. Now, I need to stop here and clarify just how large the LibreOffice snap is. The Document Foundation's download page lists the sizes of all the various installers, broken down by operating system.

Windows x64? 238 MB. Mac OS X? 201 MB. Linux x64 RPM? 229 MB Linux x64 Deb? 229 MB

So, even if you took all the installers for every OS and added them together, you would still come out at less used space than the single LibreOffice 5.2 Beta .snap package. To snap's credit, it did function. Less to snap's credit...the binary appeared to be Ubuntu-specific. Do you notice anything missing in the screenshot below?

Answer: the menu bar. I can only guess that since it was, most likely, compiled on Ubuntu, under Unity, I can only guess it's attempting to render its menu bar along the Unity top bar, which obviously does not exist on Gnome Shell. Have to call this one a peg against the idea of "compile-once, run on any distro", if the distribution the application is compiled on has significant differences towards other distributions.

* The snap used can be found here, as described in this blog post.

Concluding Thoughts

Despite some claims that Red Hat / Fedora played some role in bringing snaps to Fedora, that does not appear to be the case. Following the announcement, a discussion played out on fedora-devel that made it clear, at least to me, that Fedora is firmly behind Flatpak as the answer to Linux packaging... and frankly I don't blame them.

I know snaps are still young, and the kinks will be worked out, but I found myself leaning away from them already. It offers yet another package manager that a user, or administrator, must cover, and they do not seem to be fool-proof as originally intended. Further, I dislike their massive size... If the LibreOffice snap package was double the size of the Windows x64 MSI, I could swallow it, but at over four times as large? Sorry, count me out. Not only is that a waste of disk space, but it's also a hindrance to the actual user experience of installing it and updating it.

If third party ISV's, like Adobe, want to use snaps to distribute their applications, then fine by me, I can deal with that. But, at least right now, I think I have to throw my hat into the Flatpak camp for when it comes to installing the majority of applications.