Welcome to glick2, a application bundle system for linux

Glick2 has been designed to be used pervasively in a desktop OS, i.e. almost all applications installed and running on the system is expected to be bundles, and it would be the primary way software is shipped. I explain some reasoning for this in this (slighly out of date) blog entry.

There are several other bundle-like systems for linux, like 0install, Chakra, PC-BSD PBI. However, they are not ideally suited for an OS with pervasive use of bundling.

Here are some of the properties that make Glick2 an especially good fit for this:

Allows integration with the desktop: The linux desktop has a set of standard for how applications interact with the desktop. We use desktop files to get apps into panel menus, we have icon themes for app icons in multiple resolutions, we have standards for mimetype database extensions, dbus services, gconf schemas, etc. Glick2 supports this by allowing installed bundles to export files to a separate directory structure which the desktop can pick up. Without something like this app bundles will always be a second class citizen. Glick2 also has triggers that runs scriptlets when exported files are updated in specific places which lets us update various lookaside caches that are typically created in post install script in linux packages.

The linux desktop has a set of standard for how applications interact with the desktop. We use desktop files to get apps into panel menus, we have icon themes for app icons in multiple resolutions, we have standards for mimetype database extensions, dbus services, gconf schemas, etc. Share disk and ram for common files: Bundling means shipping all depencencies in each application. This not only means larger files on disk, but also that we might be reading the same data from disk multiple times and caching it in memory multiple times. Glick2 solves this by having all files inside a bundle indexed by a sha1 checksum, and whenever two bundles share a file with the same checksum (or even two files in the same bundle), these are automatically exposed as hardlinks in the glick filesystem. This mean that we'll only read the data for this file from one place on the disk, and we will only cache that data once in the kernel page cache.

Bundling means shipping all depencencies in each application. This not only means larger files on disk, but also that we might be reading the same data from disk multiple times and caching it in memory multiple times. Robust support for non-relocatable apps: Many bundle system require applications to be relocatable, but that isn't how linux apps typically work. Linux packages are built with a specific prefix directory, and then assume at runtime thats where its data files are. So, its easy to build packages with a different prefix, but once they are built its hard to change that. Glick uses some new kernel features like mount namespaces and shared subtrees to create a static per-bundle-instance directory prefix. Just build your packages with --prefix=/opt/bundle, and all the bundle files will magically appear there when its running.

Many bundle system require applications to be relocatable, but that isn't how linux apps typically work. Linux packages are built with a specific prefix directory, and then assume at runtime thats where its data files are. So, its easy to build packages with a different prefix, but once they are built its hard to change that. Atomic "safe" installation: A common problem with packaging systems or directory-based bundle systems is that application upgrade/removal in unsafe. For instance, if you upgrade firefox in a deb or rpm system it will replace all the data files that firefox loads at runtime, and any running instance of firefox will fail in mysterious ways as its getting the newer versions data files rather than the files it was expecting. Chrome goes to extreme lengths to avoid problems like this by using app-specific hacks. Glick2 bundles are a single file, and once a bundle is running we access all the files that the app needs via the opened file handle. So, if the bundle is replaced, or even removed, while it is running, the running instance will keep seeing the old version of the files, and only if you start the new bundle will the new instance see the new files.

Easy to install apps

Apps keep working if the OS packages are upgraded, no sudden breaks due to some library change.

In fact, you can run the same bundle on older or newer OSes, meaning you can keep running an older OS and then cherry pick new versions of apps without having to upgrade the while OS to get the new dependencies.

You can install multiple versions of the same application

Bundling leads to an increased level of cross distribution compatibility. Although, you're not bundling your own xserver and kernel, so at some point there is a dependency on system installed things.

At the moment there is just the glick-mkbundle tool, but for serious use some level of tooling would have to be created to automate the building of bundles. Various approaches are possible, including using existing packages from current distributions.

Bundling isn't perfect, there are some well known disadvantages. Increased disk footprint is one, although current storage space size makes this not such a big issues. Another problem is with security (or bugfix) updates in bundled libraries. With bundled libraries its much harder to upgrade a single library, as you need to find and upgrade each app that uses it. Better tooling and upgrader support can lessen the impact of this, but not completely eliminate it.

The code is availible in the glick2 git module in gnome git.

Alexander Larsson, alexl@redhat.com