Glick is a tool that lets developers easily create application bundles of their applications. Created by Alexander Larsson.
C Shell
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Welcome to glick, a runtime-less application bundle system for linux.

Glick is an application that lets developers easily create application
bundles of their applications. An application bundle is a single file
that contains all the data and files needed to run an application, so
all the user has to do is start it. There is no need to install it,
and if you don't like it you can just remove that file and the whole
program will be gone.

There are some interesting aspecs of the glick implementation of
application bundles:

* There is no specific runtime that needs to be installed on the
  target systems. As long as fuse is correctly installed an set up on
  the system just should not need anything but the bundle.

* The application installed in the bundle doesn't have to be
  relocatable. Glick uses a trick with the /proc/self magic link to
  find its files via an absolute pathname (/proc/self/fd/1023). This
  means that you don't have to modify applications to work with glick,
  just build then with "configure --prefix /proc/self/fd/1023".

* You can embed icons and desktop files into the target program
  file. These are stored as separate ELF sections and are very easy to

You can find news about glick and new releases at:

To build glick you need to install these required libraries:
 fuse >= 2.6.0

Then just run

to build the program, and

  make install
to install it in /usr. If you want to install it somewhere else
you can use either:

  make PREFIX=/foo install

  make LIBDIR=/foo/lib BINDIR=/foo/bin install

(This assumes glick has been built and installed)

The first thing you have to do is create a filesystem image for the
stuff your application requires. Generally you do this using something
like this:

1. mkdir /tmp/a_work_dir
 creates a work directory where we will build up the files
2. glick-shell /tmp/a_work_dir
 Spawns a "magic" shell where the path "/proc/self/fd/1023" points to
 your work directory.
3. Build your programs and install into /proc/self/fd/1023
 Generally this would go something like:
 "configure --prefix=/proc/self/fd/1023; make; make install"
 for each module you need in the image

4. Create a script or a symlink called "start" in the work dir.
 This is the program that will be started when the app bundle is
 started. If its a script it can do things like set up env vars (like
 LD_LIBRARY_PATH) before starting the actual application.

5. Create a filesystem: glick-mkext2 /tmp/image.ext2 /tmp/a_work_dir 
 This creates a minimal ext2 filesystem image from the files in your
 work directory. Due to it using loopback mounts you must run this as

6. Create the glick: mkglick /tmp/my_glick /tmp/image.ext2
 This creates a glick image. You can optionally use "--icon icon.png"
 and/or "--desktop-file my_glick.desktop" to embed an icon and/or a
 desktop file into the application bundle.

This file can be distributed to your users and should work
stand-alone, not requiring glick to be installed.

Glick bundles can contain both the application and any libraries
needed to run it. Its up to the application author to decide what
libraries to install. The more you install, the larger the file, and
the less memory is reused between applications. However, by including
libraries you can make your glick bundles more portable between
distributions. One possible approach would be to select a specific LSB
version and include all libraries you use that is not in that version
of the LSB.

Glick is not meant to replace distribution packaging system in
general. There are many reasons why distro packages can be better than
glick bundles, and there are limits to what a glick bundle can do (for
instance, it can't really extend the system). However, there are many
cases where glick bundles are very useful, as a compliment to
distribution packages. Such as shipping experimental code, or
unpackaged applications for easy testing.


Its easy to extract the various parts of a glick file, as they are
each stored in their own elf section. Glick ships with the tool
glick-extract that can do this, but it is also easy for other tools to
read this data out without relying on glick being installed.

The sections used for the data is:
    ".glick.image" - the filesystem image
    ".xdg.icon.48" - A 48x48 icon in PNG format
    ".xdg.desktop" - A xdg desktop file that describes the app


The core glick code has a BSD-style license, but it uses e2fsprogs to
implement the ext2 filesystem reading, which is licensed under the
GPLv2. This means the result is licensed under the GPL v2.

However, I belive that using mkglick to create a glick bundle
containing code that is not GPL licensed (e.g. proprietarty code) and
then distributing that is ok. This is very similar to shipping an iso
image with both proprietary and GPL code on it, which is ok due to
this part of the GPL:
     In addition, mere aggregation of another work not based on the
     Program with the Program (or with a work based on the Program) on
     a volume of a storage or distribution medium does not bring the
     other work under the scope of this License.

I've verified this with several people, but as always, I'm not a
lawyer, so if you're unsure get your own legal advice.