Bundled/ packaged apps for Linux
On unifying the existing 3 app distribution stand ards by adding 3 additionll app distribution standards 12
August 10, 2019 — December 2, 2021
Running apps in a bundled-up packaged app format keeps things tidy and includes all the necessities to run, so that an app developer can develop one version of the app rather than a different version for every desktop.
Here I focus on Linux systems, but packaging is a hot topic for other OSes too; it’s just more user-transparent for those OSes, in that the packaging systems seem to require your attention less frequently because the dominant administering corporation declares a single standard by fiat then irons the bugs flat enough that the users can ignore them.
Bundling apps seems to attempt to solve several problems at once:
- managing dependencies
- (optional) timely updates
- ease of building for a developer
- (optional) improving security by sandboxing the app packages
In practice, like every unifying standard, these meta-standards have supplemented rather than replaced the existing standards, and many app maintainers now distribute their app in up to three different packaging systems in addition to the classic OS-specific system package managers. If the maintainers do not themselves support your standard, you can usually find some package of suspect provenance maintained by a dubious stranger on the internet. Nonetheless, I understand that for many apps it is much easier to package them using one of the below systems than it is to work out the system packaging systems of Fedora or Debian or whatever, and their shifting web of dependencies.
Related, but not the same, containerization which, loosely, is more about distributing light configured machine services than desktop apps. See also sandboxing, which is often integrated with packaging, but is conceptually independent.
Open question: How do any of these standards work for dependent software, such as optional plug-ins and extensions to an app you use? In classic OS packaging systems it is natural to include various optional dependencies as small atomic packages, but it is not clear how you do this with bundled apps; For a start it seems to violate monolithic design and the popular sandboxing security model. How does that work then? Flatpak support Github extensions somehow; I should probably try to understand how they do it.
OK, are we good? So then! Here are the main players:
1 AppImage
The most minimal system.
There are .AppImage files around. See the AppImage site for information. The documentation is comprehensive. You don’t need to install anything to make these go. It’s simply an executable packaged app file format. It doesn’t necessarily (?) know how to update itself, handle cryptographic authentication etc. chmod a+x might be needed to make it executable.
Desktop integration is available via AppImageLauncher.
AppImage doesn’t sandbox at all per default, but they encourage you to use Firejail to manually sandbox. Which I will obviously never do in practice. On one hand, this is not ideal, having to manually assign permissions to everything. On the other hand, there is little evidence that package maintainers put much thought into the permissions they give sandboxed apps generally, so it is probably not substantially worse than the alternatives.
2 Snap
The packaging system Ubuntu backs. Ubuntu explains snaps and how they are used by lots of linuces and this is convenient. They are involved in a complicated controversy which is about corporate control, and limitation of early-stage technology and PR gaffes.
Snapcraft.io is the landing zone. Snaps (Snap apps) seem to be well-integrated into the desktop (the GNOME desktop at least) and low-fuss. They update themselves magically. Ubuntu has come under fire for snaps being opaque and easy to backdoor, requiring trust in the Ubuntu Czars to be the gatekeepers. That is, they are currently dubious for hardened OSes, because while they provide sandboxing, it is leaky and comes at the price of accountability.
I needed some extra config to keep disk usage under control when trying snaps. Per default, it keeps many expired versions of every app lying around for no particular reason that I understand.
or to remove inactive expired versions right now (bash shell)
3 Flatpak
I think this one comes from Red Hat?
flatpak enables many sandboxed apps via flathub. It is shiny and GUI-friendly, and seems to include update infrastructure. It claims to be a secure way of running apps sandboxed, but may not be especially secure as used in practice. Disappointingly, Flatpak apps are not called Flaps.
For Ubuntu, Flatpak is almost well supported, but not installed per default.
sudo apt install flatpak
# Integrate into GNOME:
sudo apt install gnome-software-plugin-flatpak
flatpak remote-add --if-not-exists flathub \
https://flathub.org/repo/flathub.flatpakrepoUPDATE: in Ubuntu 20.04 or later default GNOME software app no longer supports flatpak, so installing flatpak installs another version of the Software store app. The two interact confusingly.
The major pain-point of flatpak for me is the portal system, which is a bit of infrastructure that we as users would prefer to know nothing about, but which we can’t help but notice because of its obtrusiveness. When a flatpak app tries to ask a local app to open a file — e.g. a PDF view to open PDF files — rather than being a 1-click operation, it’s a tedious rigmarole, wherein a notification pops up to tell you that a PDF app selector has opened, which you click on to see the PDF selector which in turn asks how you want to open the PDF, which you must repeat anew every single time you open a PDF.
Another pain point is that Flatpak tends to rapidly consume disk space under /var.
The Ubuntu software app GUI sometimes seems to be confused about whether to install for a single user or system-wide, or both. I found I can reduce the number of duplicate copies via, e.g.
One can AFAICT execute flatpak apps directly, via, e.g. /var/lib/flatpak/app/org.zotero.Zotero/current/active/export/bin/org.zotero.Zotero, but one is supposed to do this:
If I get weird errors from a flatpak app about how it can’t access some important file, I might need to give it extra permissions.
There are many Sandbox Permissions to think about there.
Specialised GUI tchx84/Flatseal makes it explicit and Easy to Manage Flatpak Permissions.
There are various other permissions of note. Flatpak does not allow access to USB (or indeed any) devices per default. That means that if you want to access peripheral hardware you need to do
This is, if I understand what the phrasing implies, an all-or-nothing situation. Either you trust an app to access every device you have, or none of them.
4 Nix
See the package manager page.
5 Incoming
- Team Silverblue packaged apps for Fedora
- The Adaptable Linux Platform Guide Packaged apps for SUSE.