Packages

From GoboLinux

Packages are binary software packages created for use in the GoboLinux alternate filesystem layout. All installed packages live under /Programs. A package is essentially a tarball of all of the directories necessary for a typical program installation (e.g. bin, lib, sbin, etc); as such it is similar to a .tgz Slackware package ("slackage"), but meant to be unpacked in its own dedicated directory, not mixed into the rest of the system's software.

GoboLinux features both binary packages and compilation from source. Binary packages are compiled, so that you can install them quickly, without having to compile them yourself (a process which, for some packages, can take up to several hours). On the other hand, with binary packages you can't use your favorite optimization flags or generate code specific to your architecture (after all, the packaged programs are already compiled, in a generic way). Compiling from source, using rule sets that in GoboLinux lingo are called Recipes, gives you this freedom, but you have to compile it yourself -- for instance, you need to have compilation tools installed.

So, in a few words, binary packages are nice because you don't have to compile them, while source recipes are nice because you get to compile them.

Installing packages

A package can be easily installed using the InstallPackage script. You can either download the package yourself and hand it to InstallPackage, or let the script search the GoboLinux repositories by itself and fetch the package, if available. For example, if you downloaded a package and want to install it, run:

InstallPackage Gimp--1.2.3--i686.tar.bz2

If you want InstallPackage to look for the most recent Gimp package available, just run:

InstallPackage Gimp

If you want to download a specific version, give it as a second parameter:

InstallPackage Gimp 1.2.3

The script will look for the availability of the package in the GoboLinux repositories (see /System/Settings/GetAvailable.conf for the specific URLs scanned -- you may add your own repositories if desired.)

During installation, InstallPackage will run the Dependencies script to verify if there are unresolved dependencies, i.e., if the package being installed needs other (not installed) packages to work properly. InstallPackage looks for these packages in a set of default locations, both local and remote (again, see /System/Settings/GetAvailable.conf). If these needed packages are found, InstallPackage will ask if you want to install them. You may want to pass the --batch (or -b) flag to InstallPackage to suppress all interaction. This is particularly useful when installing packages like Xorg, which have lots of dependencies.

It is interesting to note that the dependency check mechanism in GoboLinux is merely informational. It will not stop you from installing a package if dependencies are missing (since it may actually work, for example, except for a single plug-in). If any unresolved dependencies remain, you are responsible to install (or not install) the packages.

Installing packages from the Live CD

To install packages from the Live CD (after booting from the HD), you must mount the 'squashfs' file that contains the image from the Live CD system. To do that, first mount the CD:

mount /Mount/CD-ROM

Then, mount the desired GoboLinux squashfs file:

mount /Mount/CD-ROM/GoboLinux-NonBase.squashfs /Mount/SquashFS -t squashfs -o loop=/System/Kernel/Devices/loop0

Now, you can install the packages that are inside the Live-CD (inside its Programs directory) using the InstallPackage script, like this:

InstallPackage /Mount/SquashFS/Programs/KDE

Note 1: after using the squashfs file, you may unmount it:

umount /Mount/SquashFS

Note 2: To have the dependencies required by an application installed automatically, use the "--batch" parameter:

InstallPackage --batch Gimp

or

InstallPackage --batch /Mount/SquashFS/Programs/Gimp

Removing packages

Due to the GoboLinux hierarchy, you can use the good and old "rm -rf" to remove installed packages. Normally, authors warn the readers to be careful when using "rm -rf". I will not do this because this doesn't work. Everybody erased the wrong things at least once. If you didn't, you didn't yet.

GoboLinux features a specific script to clean up the broken links that will emerge when programs are deleted: RemoveProgram. This script removes the program and all links that point to its files at /System/Links.

Sometimes you may want to "turn off" a program (i.e., remove the executables from the execution path, remove the libraries from the lookup path, headers, etc.) but not erase it from your hard disk. You could, of course, just move the program entry to a different directory (say, "mv /Programs/Foo "). This leaves broken links in /System/Links, which is usually harmless (but not always!... a few programs like Aclocal fail when broken links are found in its search path). A clean and easy way to "turn off" a package in a single step is using the script DisableProgram. Just call:

DisableProgram gimp 1.2.3

(As usual, the program parameter is case insensitive, and the version parameter is optional -- if not given, the "Current" link is used to infer the default version.)

To "turn the program back on", all you need to do is create the symbolic links again, using SymlinkProgram:

SymlinkProgram gimp 1.2.3

GoboLinux has also a generic script for cleaning broken symbolic links, called RemoveBroken. This is useful for performing cleanups in the /System/Links tree (typically after you move entries around in /Programs, or perform other maintenance of this kind).

RemoveBroken will verify if any of the files passed to it in the command line is a broken link, and remove those. If no arguments are passed, it receives filenames from standard input (typically through a pipe).

The usual procedure to clean up symbolic links, is, then:

cd /System/Links
find | RemoveBroken

Anatomy of a package

This section explains what is a GoboLinux package is physically, that is, what is inside a package file.

A GoboLinux binary package is simply a .tar.bz2 (or .tar.gz, though .tar.bz2 is the standard) archive. This archive contains all files from <Program>/<Version> tree. In addition to the actual program-related files (binaries, manuals, header files...), some special files are included in the package, that are installed under the <Program>/<Version>/Resources subdirectory.

These files can be present under Resources (all files are optional):

• Architecture: A file indicating the package architecture. This is simply a plain text file containing a single line such as "i686" (format compatible with the output of the "uname -m" command).
• BuildDependencies: Seems to be a list of dependencies required to build the package.
• BuildInformation: Seems to be a list of dependencies that the package was built against.
• Defaults/: files which one most likely won't want to have overwritten during an upgrade are stored in the Defaults directory, allowing the user to replace these files (or refer to them as a backup of the original state of the configuration files) at their discretion.
  • Settings/: the default/initial state of the program settings. If, when installing a package, there is no pre-existing Settings tree for the program in the system, these "default Settings" are copied to /Programs/<Program>/Settings. Otherwise, the default settings and existing settings are merged using the UpdateSettings script.
  • Variable/: ditto, for "variable" (local state) files. These files, if not already existing, are copied directly to /System/Variable (local state files are stored directly in /System/Variable so that "var" files can be isolated in a separate partition and maintained in a site-local manner independently of package additions/removals).
• Dependencies: Contains a list of packages on which this package depends. The Dependencies file is created by the Dependencies script. It is a plain text file, containing one entry per line, in "App 1.0" format.
• Description: Program description, in plain text format.

[Name] Sampleapp
[Summary] A very important app
[License] GNU General Public License (GPL)
[Description] a description of  the program
[Homepage] http://www.just-an-app.com/

• Environment: a file listing a series of shell 'export' commands, setting environment variables.
• FileHash: MD5 checksums of all files in package tarball.
• FileHash.sig: GPG signature of FileHash
• Hints: Insufficient data, but seems to be a Install configure package affecting a single package.
• MetaData: Generic meta-data store which seems to formatted like the Description file.

Name: SampleApp
Version: 1.0.0

• NewDependencies: Seems to be an optional list of dependencies. format seems to be space separated package name/version pairs each on an individual line.
• PostInstall: Seems to be a script to be run after the package is installed
• Requirements: Seems to be a list of required users and groups. White-spaces don't seem to be used consistently.

required_users=("nobody")
required_groups=( "nothing" "nowhere" )

• Revision: Seems to be a version for the recipe. One line containing a small counting number prepended by the upper-case letter R. ex 'R3'
• Tasks/: boot scripts can make use of "boot script tasks", which are little service scripts that can be shipped by programs. This is roughly equivalent to the /etc/init.d scripts found in many distributions.
• Unmanaged/: Files to be inserted outside the /Programs Hierarchy only if no file exists there?
• UnmanagedFiles: list of files/directories to not be updated in the Unmanaged directory mentioned above.
• UseFlags: List of use flags the package was built.
• Wrappers/: a directory containing additional app-specific helper scripts written especially for GoboLinux.
• XmlCatalogData: something to do with XML pacakges (imports and rewrites?)

In the future, Environment should evolve into a directory, containing one file per variable. The name of the file will be the variable name and its contents, the variable content. The only shell code allowed inside an environment file will be referencing other variables in $var or, preferrably, ${var} format. This is an attempt to improve portability of the declaration of Environment variables.

Creating packages

Once you have a package properly compiled and installed (as explained in the previous section), creating a binary package is quite easy. Simply call the CreatePackage script passing as parameter the package name. For example:

CreatePackage rxvt

This will create a binary package in the current working directory.

Please be careful with the contents of the Settings directory when creating a binary package, so that it does not include personal information. A package submitted for inclusion in the packages directory at http://www.gobolinux.org must feature sensible default settings, preferably the defaults as specified by the application right after its compilation.