Linux

My view on Flatpak/Snap packages

There has been a lot of talk in the Open Source world about universal package formats. Specifically the big two, Flatpak and Snap packages. My current Linux desktop distro of choice, Solus, has recently announced support for them. Now, this has a lot of pros and cons and whilst I have seen and heard a lot of the positive points I want to put across what is probably my more unpopular point of view.

These universal package managers make it easier to create one application build and run it on multiple Linux distributions. This means the software bundle will be typically larger because it will need to also pull in specific versions of any dependencies that the distribution will likely not have in their repositories.

Not only does this mean that the packages take more disk space but will also often lose the memory usage advantages of shared libraries. Having a background of writing things for embedded platforms where memory is at a premium and services that need to be lightweight for performance this gives me an uncomfortable feeling.

The second reason this is a problem comes from past experience working for a very popular Open Source project. I’ll tell the brief story…

We had a new feature coming to our project, we’ll call it feature X for now. To use it a big company who rhymes with “Frugal” forced us so that we could only make this work with version 1.1 of library Y. The problem is no LTS Linux distro had yet shipped with 1.1 of library Y.

Now, we could have easily put version 1.1 of library Y into our package repositories for people to use. But this effectively means we are maintaining product Y for security and bug fix updates as well as our own software. You know what? Linux distribution maintainers are really good at making sure their libraries are up to date with security fixes. We did not want to manage this package and eventually LTS releases added the new version of the library and users could use feature X.

This to me is a similar situation with the universal package formats. Instead of the Linux distributions maintaining security updates of dependencies this relies on the software maintainer/packager to do it.

Yes, you can silo a universal package in a container, but there are ways to break the security of containers and containers will not protect your data the application has access to.

Now, does it make it easier to ship? Maybe, a good CI/CD pipeline would automate this process for multiple distributions quite easily for native package formats. SUSE also have a build service you can use to build packages for multiple Linux distributions.

The biggest valid use-case I can see for universal packages is commercial software, it is much easier to silo and much easier for commercial software maintainers to distribute (some are notoriously bad at releasing for current distributions).

I’m not sure yet how comfortable I feel about making commercial software easier for Linux. I feel it could mean that more people start making software available using less open licenses.

I’m not saying that it wouldn’t be great to have some kind of package that worked great on all Linux distros. To do it in a way that is compatible with the shared libraries in those distros without static linking is hard. The current state of the whole thing makes me uncomfortable, or maybe I’m just getting old…

 

Image credit: Frustration by Eric used under a Creative Commons license.

LinuxJedi

Share
Published by
LinuxJedi

Recent Posts

Working with the AVR Dx family

In recent years, Microchip has launched a new range of AVR chips. They appear to…

4 days ago

My WordPress Slack ban

A couple of days ago, I got banned from the WordPress community Slack. As this…

5 days ago

Issues I found during WordPress.com to .org migration

Whilst migrating from wordpress.com to an installation of the open source WordPress, I hit some…

1 week ago

Why I moved my blog

Unfortunately, there is a war going on within the WordPress community. To stay as far…

1 week ago

Four new Amiga products for September 2024

Since the June Amiga Expo, I have been developing some new Amiga related products. I…

3 weeks ago

Repairing an Amiga that caught on fire!

Karl at Retro32 likes to challenge me, and this time he had an interesting one.…

1 month ago