The Living Thing / Notebooks :

Packaged apps for Linux

On having 3 extra suggestions for installing that app on top of the existing 12

Usefulness: 🔧
Novelty: 💡
Uncertainty: 🤪 🤪 🤪
Incompleteness: 🚧 🚧 🚧

Running apps in a packaged format keeps things tidy and cross-platform, so that an app developer can develop one version of the app rather than a different version for every different desktop. In practice, app maintainers now have to distribute their app to three different packaging systems so it’s not clear there is an overall win here. Noetheless, I understand that for many apps it is much easier to package them using one fo the below systems than it is to work out the system packaging systems of Fedora or Debian or whatever.

Here I focus on the 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 do not seem to require you to pay attention.

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.

OK, are we good? So then! Here are some systems I have encountered.

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 ho 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 remember to 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.

Snap

The packaging system Ubuntu backs.

Ubuntu explains snaps and how they are used by lots of linuces and this is convenient. 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.

I need some extra config to keep disk usage under control. Per default, it keeps many expired versions of every app lying around for no particular reason that I understand.

sudo snap set system refresh.retain=2

or to remove inactive expired versions right now (bash shell)

sudo bash
snap list --all | while read snapname ver rev trk pub notes; do
    if [[ $notes = *disabled* ]];
    then snap remove "$snapname" --revision="$rev";
    fi;
done

Flatpak

I think this one come from Red Hat or Fedora?

Disappointingly Flatpak apps are not called Flaps. 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. It is at least, tidier for package maintainers so makes it easier to distribute software. The cost is that desktop integration is only kind-of functional.

For Ubuntu, Flatpak is almost well supported, but not installed per default.

sudo add-apt-repository ppa:alexlarsson/flatpak  # before 18.10
sudo apt install flatpak
sudo apt install gnome-software-plugin-flatpak  # Integrates into GNOME
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

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 obstrusiveness. 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, telling you that a PDF app selector has opened, which you click on to see the PDF selector which it in turn asks you then asking you anew each time which PDF app you would like to use. Every single time.

Another pain point is that Flatpak tends to rapidly consume disk space under /var.

If you get weird errors from a flatpak app about how it can’t access some important file, you might need to give it extra permissions.

flatpak override --user --filesystem=/path/to/dir org.app.Id

The Ubuntu software 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

sudo flatpak remove --system org.zotero.Zotero
flatpak install --user org.zotero.Zotero

One can AFAICT eexcute 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:

flatpak run org.zotero.Zotero