Contain this
Aaron Peters went all in on Ubuntu’s .deb package format years ago, and has never looked back. That said, there’s always time for a second opinion...
There’s a new sheriff in town, well, there isn’t but look Aaron Peters went all in on Ubuntu’s .deb package format years ago, and has never looked back. That said…
Linux has made great strides in the area of software compatibility. Or, more accurately, software is available more consistently across the various distributions and their native package formats. Yet this still requires the hard work of packagers. They need to take an application and tweak it to fit the specific needs of different distros, and even different releases of the same one. However, a few new universal package formats have emerged, bringing the promise of “package once, run anywhere” (on Linux, anyway).
Flatpak (https://flatpak.org) is among the contenders Mayank Sharma reviewed in LXF234, and it’s got a lot going for it. In this article we’ll examine
Flatpak, explore how to use it, and take a look at two important developments.
Mode of operation
Flatpak is both a package format, and a tool to install and manage those packages. Many Linux package formats work on the concept of dependencies, which means a developer can define that package A depends on package B. When a user tries to install my package A, the system will recognise the dependency and install package B along with it. This is how you apt install one application, and end up with a hundred packages to be downloaded and installed.
In contrast, Flatpak provides you both the application and everything it needs to run in a distro-independent format. This approach has its pros and cons:
Yet the basic idea behind Flatpak is attractive. Find a program, install it easily, and run it without worrying about what else on your system may be using an incompatible version of the same library. Furthermore, installing applications as Flatpaks enables you to mix and match programs in ways you can’t with your normal package system, such as: Using the bleeding-edge version of an application, while keeping the standard version as well. Example: LibreOffice, shown in the screenshot (on page 74) running versions 5 and 6 at the same time.
You have security concerns, and feel better with the program operating in a sandbox. Example: Adobe’s Flash Player. To use a more recent, more stable, and/or more fullfeatured version of an application than your distribution provides. Example: Calibre, which is well behind even on Ubuntu 16.04. Yet as we saw in LXF234, there are other formats that provide similar advantages. These include Ubuntu’s Snap format (www.snapcraft.io) and AppImage (https://appimage.org). While they all perform similar functions, Flatpak has a leg up on the competition in a couple of ways:
Snapcraft is a Canonical project, and while it’s available in other distributions, it’s a first-class citizen of Ubuntu. If you use another distro, or just prefer a software system that’s not controlled by a single, commercial entity, Flatpak is a better choice than Snap.
AppImage takes the approach of simply downloading and running a single file. This is straightforward, but not necessarily easy, especially for new users. First off, you need to set the downloaded AppImage file to be executable before you can run the app. In addition, there isn’t a built-in mechanism to update your AppImages. The project offers an external tool to do so, but you need to download and configure that yourself as well.
Despite all this talk of pros and cons, you can use any (or all!) of the above formats on your machine at the
same time. That defies logic, doesn’t it? How did the developers accomplish this? Let’s examine the Flatpak format a little more closely to find out.
Unpacking Flatpak
Like most open source projects, Flatpak stands on the shoulders of giants to accomplish its goals. Two key technologies behind Flatpak are ostree and bubblewrap.
When you install a Flatpak, you’re installing an ostree “bundle” containing the application. The project’s website describes it as something like “git for operating system binaries.” In addition to other benefits, this approach provides for atomic updates, which is a fancy way of saying that only what needs to get updated, gets updated. It also provides a rollback mechanism.
Suppose you have a program with file 1 and file 2. An update provides a new version of file 2, which is actually designated file 3. The program will operate quite happily using file 1 and file 3 until you want to roll back a version. But you won’t need to do a whole uninstall/reinstall operation. You just need to change the application so it uses file 2 instead of the newer file 3 (which still exists, in case you want to “roll-forward”).
The other helper technology is bubblewrap, a software layer that in turn uses the Linux kernel’s user namespaces feature. It enables non-root user accounts to serve as root accounts in containers, including a
Flatpak sandbox. When you run a Flatpak application it’ll start a sub-system consisting of the Flatpak application and a select number of system resources for the sandbox to use. The FlatPak wiki on GitHub (https:// github.com/flatpak/flatpak/wiki/Sandbox) has a page that describes the contents of the sandbox in detail, but some key attributes are:
The application’s runtime(s) are mounted in the sandbox within /usr (the structure of which is explained in more detail in the box (right). The application itself is mounted within /app. Configurations from the host /etc directory are mounted to the sandbox’s /usr/etc.
Only processes in the sandbox are visible from the sandbox, for example the /proc directory.
Assets such as icons, fonts and so on are available through “bind-mounts,” or mounting one file/directory (outside the sandbox) to a different spot in the filesystem (within the sandbox).
Overall, the sandbox has access only to the resources it needs to function, and then only with the least possible privileges.
Now, if you’re not too confused yet, we’ll add another level of complexity. Because while most software requires root privileges to install on a Linux system, normal users can install Flatpaks. In the next section we’ll examine the difference between these “user installs” and a more traditional “system install.”
System versus User
Seasoned Linux users are accustomed to providing a root password when installing software. That software ends up in a directory outside your $HOME, such as
/usr/bin, /opt or perhaps even /usr/local. But as mentioned in our pros list, Flatpak supports the ability to install a program for a specific user, as opposed to the entire system. This works because a normal user has access to the necessary resources to run a program,
and the sandboxes created by the user receive this same access.
When you run any of the install commands we’ll see in a few moments, you’ll be prompted for your password. This is because Flatpak will carry out system installs by default. What this means is that a program will be available to all users and that its files will be stored in /var/lib/flatpak.
Alternately, if you use the --user flag with a command – it’ll just install for your account (you shouldn’t be prompted for a password). The files in this case will be in $HOME/.local/share/flatpak. This is useful if you don’t have an administrator account on your machine, or perhaps if you want to try a bleeding-edge version of a program that’s installed elsewhere on the system.
The user install is possible because of how the sandbox is constructed. Think of it this way: as a user, you have the ability to run an application. That application has the rights (through your user account) to create an on-screen window, write files to disk, and access network connections. When you install a Flatpak as a user, any resources from the host system are limited by what you yourself could access with a “normal” program.
Installing Flatpak
The first component you need to install Flatpaks (the package format) is Flatpak (the application). Most distros provide it in their repositories. In Ubuntu, you can issue the following to get up and running: $ sudo apt install flatpak
This will, of course, give you the version that’s packaged with the current version of your distro. If you’re on a long-term support version, such as Ubuntu’s 16.04 (Xenial), this may mean you won’t get newer features. Installing from the official Flatpak PPA is the recommended way to make sure you always have the most recent version:
$ sudo add-apt-repository ppa:alexlarsson/flatpak $ sudo apt update $ sudo apt install flatpak
Once it’s installed, you’ll be able to install Flatpak programs using the command line. But some GUI package managers also have support for the format. KDE’s Discover, for example, can manage your Flatpak files if you install the appropriate backend.
With the right tools installed, there’s one quick step to take before you can start hunting for some new apps.
Flatpak hubs
Flatpak seems to have adopted the term hubs to describe collections of software, just like RPM or DEB repositories. The Flatpak site itself hosts the first one you should add, FlatHub. Register it with your system using your package manager, or at the terminal with the following command: $ flatpak remote-add --if-not-exists FlatHub https:// flathub.org/repo/flathub.flatpakrepo You can see a list of your configured hubs by running $ flatpak remotes
On the menu
There are a couple of different application types that lend themselves to being packaged as Flatpaks. The first of these is commercial applications. If the developers of commercial products don’t make it easy for the community to pick their applications apart, it’s solely up to them to package everything.
Flatpak gives a single target for packages that will work across distros, and sandboxing the apps can help reduce support costs. Some examples of commercial (though free) programs in Flathub include Steam, Slack, and Sublime Text.
Another type of application that makes a good Flatpak is large, complex applications. These benefit from Flatpak’s atomic upgrades, making the update process a little less painful, and the roll-back process even less so. LibreOffice, which is normally a 200MB update, and Android Studio, which is even more, are both available as somewhat more convenient Flatpaks.
Finally, cross-platform apps already have two completely different OS targets (at least for desktop, even more if they’re mobile). Developers and packagers surely don’t need to worry about the idiosyncrasies of a dozen Linux distros on top of that. Just wrap your app up as a Flatpak, and you’re good to go.
Installing Flatpak programs
Installing applications from the Flatpak will feel very familiar if you’re accustomed to using apt or either yum
or dnf on your system. The search command will show you hits in any of your configured for the keyword that you provide: $ flatpak search calibre
This will return a result for the excellent Calibre e-book manager, which is often out of date in the Ubuntu repositories. Note the first column, which gives the Application ID in a sort of reverse-domain format (com first, then domain, and so on.). You’ll need to give this to the install command for Flatpak to install your program: $ flatpak install com.calibre_ebook.calibre
At this point Flatpak will start downloading and installing your application and any runtimes (org. freedesktop – see the screenshot, below right) it requires. A runtime is a collection of libraries and other software for the application. It’s the Flatpak way of resolving your dependencies for you. “Wait,” you might say, “isn’t this what apt and
yum do for me?” It’s a fair question. There are a few notable factors that set runtimes apart from normal Linux dependency management.
Flatpak’s sandbox environment ensures anything you install won’t conflict with your system proper.
A runtime is a fixed set of software, so you know you’ll get exactly you need to run the app – no more, no less.
Flatpaks are built against specific runtimes, so there’s no need to worry about upgrades breaking your program all of a sudden.
The trade-off boils down to confidence that the program will always have what it needs to run as intended, but note that it’ll need to take up more disk space to do so.
There are a couple of other methods you can use to install applications. If you happen across a rogue Flatpak and download it, install it from the command line using the command above: $ flatpak install somefile.flatpak
Finally, Flatpak provides a method for installing an application by running an installation file. This file, called a flatpakref, contains some metadata about the program, including: Its full name. The hub from which it should be downloaded. Its version Whether it is a runtime or not. Its GPG signature. Installing from a flatpakref file is the same as installing from a locally downloaded Flatpak file: $ flatpak install ./somereffile.flatpakref
You can also use a GUI package manager, which should display and install Flatpaks in the same way it does other packages (provided that you installed the backend).
Running Flatpak programs
Once your program is installed, you can launch it from the command line as follows: $ flatpak run com.calibre_ebook.calibre
Once the program starts up, there are a couple of things you’ll notice. The first is that you’ll have access to all your normal $HOME directory files. “But, but,” you’ll ask, “I thought the Flatpak sandbox was isolated from the rest of the system?” That’s very astute of you. However, running a program that can’t interact with your files isn’t very useful. The Flatpak developers have worked around this.
You should also see entries for the application show up in your desktop’s menu. If you don’t see them, check the Quick Tip (left) for how to try and fix this. Actually, under most circumstances, you shouldn’t be able to tell the difference between these programs and those provided by your distribution. You can operate on your files, play multimedia files, and generally use them as a “normal” program.
Managing your Flatpak installs
Once you have a Flatpak or two installed, you can, of /, course, use your GUI package manager to administer them. But if you prefer the terminal, some of the below commands will be useful. You can list the Flatpaks (both apps and runtimes) you have installed with the following command: $ flatpak list
The result displays not only the installed modules, but also their installation type (system/user). You can update all your Flatpaks with a single command, just like native package managers: $ flatpak update In the event you need to remove a Flatpak, enter the following at the prompt: $ flatpak remove [full-qualified app name] If you need to remove one of the hubs you’ve configured, you can do so with the following: $ flatpak remove-remote [name of remote]
Conclusion
The benefits of the Flatpak format are numerous. It provides developers with an option to target multiple distributions, while giving users multiple tools to install the resulting applications. It enables programs to access the resources they need, while restricting them from the things they don’t. It works around some of the dependency problems of traditional packaging formats, at the expense of a little disk space. Finally, it opens up opportunities for developers to wrap up applications that are traditionally tedious to install in a format that’s drop-dead simple. So if you want to try out the cutting-edge version of
LibreOffice or run a Wine-based game like World of Warcraft, give Flatpak a try. You really can’t go wrong!