When Linux set off on its successful journey back in the 1990s, some innovative software management solutions also emerged. As early as in 1994, the Debian Package Manager dpkg was introduced, and the Red Hat Package Manager RPM followed suit in 1997. Since then, numerous other package management systems for various distributions have seen the light of day.

What they all have in common is that they not only maintain centralized software repositories with applications, but they also let users install, update, and uninstall applications in a largely trouble-free way. All of the popular candidates can handle dependencies and conflicts and keep the respective system in a consistent state. This is why individual installation routines for applications with a jumble of different dialogs, which are commonplace on other operating systems, do not exist on Linux.

At the same time, the known tools are flexible enough to include additional software archives beyond the repositories provided by the distribution developers and again offer the advantages of centralized package management. The built-in package managers on traditional Linux distributions work on the command line. However, graphical front ends such as YaST or Synaptic quickly emerged for less experienced users, helping them to handle software administration conveniently at the push of a button.

Having said this, the veteran package management tools come with some drawbacks. Depending on the update cycle of the underlying operating system, they occasionally have outdated software versions including partly outdated interfaces. The biggest problem is that the individual binary packages available in the different formats are not mutually compatible. To a limited extent, you can convert DEB and RPM packages to the other format using the Alien [1] tool, but you cannot achieve general compatibility.

In order to work around this shortcoming and launch further innovations, cross-distribution package formats have emerged on Linux in recent years. Each of them can be integrated into existing Linux installations with their own management systems.

AppImage

The AppImage [2] package management system contains cross-distribution application packages. You will always find all the program libraries you need there. The packages are actually compressed drive images that use the SquashFS file system and are located in the /tmp directory. As soon as you exit the application program, the mount point is released again.

After downloading an AppImage package, you need to assign it execution privileges using the chmod +x PACKAGE command to run it without being root. Because you do not install on the operating system, it isn't a problem to run two or more different versions of the same program at the same time. And, if needed, you can alternatively install and run the same program – if available – from the repositories.

AppImage packages are frequently a poor fit for the work environment and require some manual work. Only a few applications ask, when first called, whether you want the application to be integrated into the existing menu structure. In addition, AppImage packages do not give you automated updates, and legacy routines for updating application programs and libraries will not have any effect.

It is important to note that AppImage packages run with the permissions of the user who launches them. This means that the application has the same access rights for the system as permanently installed applications, which can cause security issues. Make sure you only retrieve the packages from trusted sources, and never launch AppImage packages with root privileges. There are now numerous graphical tools that facilitate the integration of AppImage applications with existing Linux systems.

AppImageLauncher

One of the main candidates here is AppImageLauncher [3]. The software integrates the AppImage packages into the menu structure of the respective work environment and additionally – if supported by the respective AppImage package – triggers an update of the application. The tool integrates itself into the graphical menu of the distribution you are using and displays a setup dialog when you first launch it, letting you configure the basic settings, such as the search path to the AppImages and the update function (Figure 1).

Figure 1: The Settings menu in AppImageLauncher turns out to be spartan.

You can then open AppImage packages from the file manager without having to give them execute permissions first. In addition, the AppImage programs can be launched directly from the working environment menu hierarchy because AppImageLauncher enables automatic integration of AppImage packages by default. If you manually set the execution rights for newly downloaded AppImage packages and then call these packages at the prompt, AppImageLauncher automatically opens a dialog that lets you add the package to the menu at the push of a button (Figure 2).

Figure 2: AppImageLauncher automatically pops up to facilitate the integration of an AppImage into the desktop.

AppImageUpdate

AppImageUpdate [4] is another graphical tool which you invoke manually after downloading and assigning execute permissions. Then use the small file manager to select the AppImage packages to be updated (Figure 3). But be careful: The tool can only update the desired packages if the developers of the respective package have included automated updates as a feature of their software.

Figure 3: AppImageUpdate lets you update your AppImage packages automatically.

For all other AppImage packages, AppImageUpdate exits with an error message. If the update is successful, the program will display a progress bar in a separate window. If required, pressing Details provides more detailed information about the update (Figure 4).

Figure 4: AppImageUpdate reports the successful update in a separate window.