A while ago, someone e-mailed me with a request to add Flatpak to my repository. At the time, I had no interest in Flatpak, had not actually bothered to investigate it, so I said “sorry, no” and dismissed it.
Still, my curiosity was piqued, because I have been having long-time struggles getting our company version of MS Teams up and running on my Slackware desktop, and Flatpak could offer resolution. I am an advocate of running natively compiled code on your Slackware OS, and the software that I am using regularly is all available in my repository as packages that have been compiled on Slackware from source. But Open Source is all about choice, and more power to you, right?
I am realistic enough to see how self-contained binary software distributions can have an appeal to people. These days, more and more new software releases are made available as AppImages, Snaps or Flatpaks. The developers won’t have to worry about maintaining friendly relationships with distro packagers who may or may not do the packaging work for them every release. In fact, distribution mechanisms like Flatpak finally place niche distros like Slackware on the same level as their more widely used brethren like Ubuntu or Mint. The Flatpak app will run on all of them, unmodified.
The downside of course, is that this bundling of a program plus all its dependencies will increase the size of the on-disk installation. A natively-compiled package relies on dynamic linking to the libraries which are provided by the OS, but the Flatpak needs to bundle its own compatible copies of all those libraries. Lean versus bloat. Convenience has its own sacrifices.
For me as a Slackware packager and coreteam member, it is more important to offer options than to be a zealot. If a tool like Flatpak brings you more joy using Slackware on your computer, who am I to deny it to you?
Bringing it to Slackware
So I dove into the available Flatpak documentation (it is very extensive!) and also I went through the Flatpak submission on SlackBuilds.org to see if there were Slackware-related challenges to be overcome. Seems like the only hairy topic may be that of getting sound out of the Flatpak and into your speakers, but so far I have not messed with audio. On first glance audio works out of the box on Slackware64-current in a Plasma5 desktop session, where I tested an Internet radio player.
I will update this article once I understand the concepts better and can share proper and fool-proof instructions.
The versions of flatpak and its dependencies found on SBo are limited by the versions of libraries in Slackware 15.0, hence you won’t find the latest version of Flatpak there. For Flatpak 1.14.0 you really need to be running Slackware-current.
It’s not just about Slackware’s own provided libraries; the external dependency requirements also changed between Flatpak 1.12 and 1.14. I use both Slackware 15.0 and -current, therefore I have built two parallel sets of packages; one for Slackware 15.0 and another for -current.
On Slackware 15.0 you’ll get appstream-glib, bubblewrap, gcab, libostree and xdg-desktop-portal-gtk to support Flatpak 1.12.0. For Slackware-current I can offer Flatpak 1.14.0 (latest release) and because it switched from requiring appstream-glib to appstream, the supporting packages on -current are: appstream, bubblewrap, libostree and xdg-desktop-portal-gtk.
Note that my ‘libostree‘ package is called ‘ostree‘ on SlackBuilds.org, but the software changed its name and I am using the new name here.
My Flatpak package registers the FlatHub repository as a system-wide remote upon installation. It also creates a ‘flatpak‘ user (with the same UID and GID numbers as reserved but not yet used by SBo). Flatpak uses this as a system helper account.
Why Flatpak at all
All the rage nowadays is to containerize applications and distribute them in a “build once, run everywhere” fashion, pretty much isolated from the host Operating System and using kernel capabilities to interact with that OS.
One example of this is Docker. I have been providing Docker packages for a while and have written an article series about setting up your private cloud server using Docker. Docker is a framework to deliver server applications via containers and it does so quite well.
But to ‘containerize’ graphical desktop applications that interact with your Slackware desktop environment – adding a desktop menu item, allowing access to your local files, and play audio? That is a whole different ball-game. For this, you have the aforementioned solutions like Flatpak, Snap or AppImage. They all are conceptually similar but have different architectural design considerations.
I have no preference for either. Prior to researching Flatpak I had not used any of them. Picking Flatpak was driven by Slackware user request, simple as that.
Flatpak runs its apps in a secure virtual ‘sandbox’ which does not require root privileges. This mitigates potential security threats.
Like with AppImage or Snap, this sandbox environment contains everything that is required to run the software. This makes it possible to build a self-contained Flatpak application and then run it on any distro transparently.
If you want to know the internals of how Flatpak works, there is a nice article here: https://docs.flatpak.org/en/latest/under-the-hood.html . Main takeaways are that Flatpak relies on OSTree as a system for versioning and distributing filesystem trees (inspired by how git maintains a repository of source code but then for binaries); Bubblewrap to allow unprivileged users to set up and run containers, using kernel features such as namespaces, bind mounts and seccomp rules, and Appstream to provide the infrastructure that allows application installers to interact with the OS in a well-defined manner.
Getting to know the commandline
Let’s play a bit with the commandline tool straight after installation and a logoff/login (or running ‘source /etc/profile.d/flatpack.sh‘.
To get details of the already configured remote repositories, run the following command:
$ flatpak remotes -d Name Title URL Collection ID Subset Filter Priority Options … … Homepage Icon flathub Flathub https://dl.flathub.org/repo/ - - - 1 system … … https://flathub.org/ https://dl.flathub.org/repo/logo.svg
List available packages in a remote repository:
$ flatpak remote-ls | less AuthPass app.authpass.AuthPass stable x86_64 BlueBubbles app.bluebubbles.BlueBubbles stable x86_64 Blurble app.drey.Blurble stable x86_64 Dialect app.drey.Dialect stable x86_64 EarTag app.drey.EarTag stable x86_64 KeyRack app.drey.KeyRack stable x86_64 Warp app.drey.Warp stable x86_64 Space app.getspace.Space stable x86_64 Lith app.lith.Lith stable x86_64
Will I get the same listing for my own user?
$ flatpak remote-ls --user
Actually, this command comes back empty. This is because Flatpak works in two modes: the default mode is to manage packages system-wide; but alternatively you can manage apps in your own homedirectory as well.
For Flatpak apps that are downloaded into your homedirectory location ‘~/.local/share/flatpak‘, you do not need any special privileges, you just need to add the commandline parameter “--user” to any flatpak command-line that you use.
For system-wide package installations which go into ‘/var/lib/flatpak/‘ you either run the flatpak commands as root, or else you will get a prompt to enter the root password prior to the actual download and installation.
The above listing is empty because I still need to enable the FlatHub repository for my own user (remember, the package registers that repository system-wide only).
Using flatpak as regular non-root user:
Let’s add the Flathub repository to your own user account so you can install and manage applications without the need for root’s password:
$ flatpak --user remote-add --if-not-exists flathub /etc/flatpak/remotes.d/flathub.flatpakrepo
Search for a package:
$ flatpak search minetest Name Description Application ID Version Branch Remotes Minet… Multiplayer infinite-world… net.minetest.Minetest 5.6.1 stable flathub libre… a opensource tile game eng… ….celleron56.libretile 2.5 stable flathub
Sometimes when your terminal is not wide enough, it’s more readable to list only a subset of columns:
$ flatpak search minetest --columns=name,application Name Application ID Minetest net.minetest.Minetest libretile io.gitlab.celleron56.libretile
Install a package from the flathub repository:
FlatHub is the default repo so you can omit the keyword ‘flathub‘ here, but suppose you have defined more than one repo…
$ flatpak list
<empty>
$ flatpak install flathub Minetest
<lots of activity...>
net.minetest.Minetest permissions:
network pulseaudio x11 devices
$ flatpak list
Name Application ID Version Branch Installation
Minetest net.minetest.Minetest 5.6.1 stable system
Freedesktop Pl… org.freedesktop.Platform 22.08.2.1 22.08 system
Mesa …eedesktop.Platform.GL.default mesa-22.1.7 22.08 system
openh264 …freedesktop.Platform.openh264 2.1.0 2.2.0 system
As you see, not just Minetest got installed, but additionally some dependencies that were missing from my local Flatpak repository. One of the benefits of the underlying OSTree filesystem management is that a dependency which is requested by multiple apps, will only be downloaded and installed once.
Also worth pointing out that at the end of the ‘flatpak install‘ command, you’ll be notified about the permissions the app will require from your local OS and desktop environment. Minetest will want to use your network, play audio, run as a X11 graphical application and enumerate your peripherals. Remember that this is a sandboxed application, which will request these permissions outside the sandbox through kernel capabilities.
Where to go from here?
There are still kinks I have to resolve, which is why I uploaded the packages and wrote this blog article. I need your help.
I ran the above installation as my regular user and got more than 10 ‘policykit‘ popups prompting me for the root password. This is bad, and I need to find out how I can reduce this to only getting prompted once.
I can not find Minetest in my XFCE desktop menu, even though I see the file “/var/lib/flatpak/exports/share/applications/net.minetest.Minetest.desktop“. The question is: as far as I understand, appstream-glib is responsible for the desktop integration but it seems to fail. Or perhaps XFCE is not supported? In KDE Plasma5 on my slackware-current laptop an installed Flatpak app nicely integrates into the desktop menu.
And on my Slackware 15.0 machine I could not start Minetest as my regular user, and had to run it as root because of this error:
$ flatpak run net.minetest.Minetest
bwrap: Can't mount proc on /newroot/proc: Operation not permitted
error: ldconfig failed, exit status 256
There’s an old post on LQ.org which suggests that my NFS mounts or a running RPC server could cause this, but I cannot stop NFS here. Other posts suggest that user namespaces are required to get rid of the error, but Slackware already has those enabled by default:
$ zcat /proc/config.gz | grep CONFIG_USER_NS CONFIG_USER_NS=y
When first becoming root using ‘sudo -i‘ and then running “flatpak run net.minetest.Minetest” I can get the app to start properly except for this audio related error:
ERROR[Main]: Audio: Global Initialization: Failed to open device
Any insights are welcome of course. Please post them below in the comments section and if any changes need to be made to the SlackBuilds, that’s what I will do.
Discover on KDE Plasma
For users of the Plasma desktop environment, I have added discover to my repository. Discover is a software package management tool that is part of KDE Plasma, but Slackware does not ship the application because it has no support for Slackware repositories. However it does support Flatpak, if it is compiled while Flatpak is available on the system.
So that is what I did: I built a discover package with Flatpak support.
This is how Discover presents itself after already having installed Minetest via the commandline:
There is one thing which I think is worth investigating. Flatpak’s package management is not compatible with the Slackware tools like slackpkg or pkgtools. It would be nice to manage all your software centrally, and what do you know… Discover supports not only Flatpak as backend but also PackageKit. I wonder how well PackageKit’s own Slackware backend works these days, but finding out is very low on my TODO. I leave the exercise to you, the reader.
Happy hacking, and I love to hear your usage stories!
Eric
Recent comments