Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
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 extract. You can find news about glick and new releases at: http://www.gnome.org/~alexl/glick/ BUILDING AND INSTALLATION ========================= To build glick you need to install these required libraries: fuse >= 2.6.0 e2fsprogs Then just run make 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 or make LIBDIR=/foo/lib BINDIR=/foo/bin install HOW TO CREATE A GLICK BUNDLE: ============================= (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 root. 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. EXTRACTING DATA =============== 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 LICENSING ========= 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.