Subsections of How-To's

Contributing to the Wiki

We greatly value community contributions to our wiki! If you notice any gaps or errors in the documentation, you have the power to make a difference!

Simply click the edit button ✏️ in the top right corner of any wiki article to access an editable form on GitHub. We use Markdown formatting, by the way.

The wiki’s content and source code are housed in a dedicated repository on Github.

Check out the README for guidance on navigating the wiki’s code, or feel free to file an issue if you need assistance!

Manual Compile

Building and installing manually from source. This should only be done if one is unable to create a recipe or as an excercise. With very few exceptions, the work of creating a recipe is rewarded by the ease of using Compile.

See also: Advanced → Steps of the compile process

Note

If you use a local tarball, be sure to have the tarball placed at /Data/Compile/Archives. Also make sure you know whether you have a recipe locally or not, if you ie do not have access to the www on that machine.

I’m using dosbox from CVS as an example here.

First, go into the folder where you have the source (change directory).

phed@Arjuna ~/]cd dosbox
phed@Arjuna ~/dosbox]

Run PrepareProgram with the option -t or –tree to generate the directory tree in /Programs/DOSBox/CVS.

phed@Arjuna ~/dosbox]PrepareProgram -t DOSBox CVS
phed@Arjuna ~/dosbox]

Then run PrepareProgram again without options to run configure

phed@Arjuna ~/dosbox]PrepareProgram DOSBox CVS
PrepareProgram: Preparing...
PrepareProgram: Autoconf configure script detected.
checking build system type... i686-pc-linux-gnu
...
config.status: creating config.h
config.status: executing depfiles commands
phed@Arjuna ~/dosbox]

Then we have to do whatever is required in order to build the application. In the case of DosBox we have to issue make in order to compile the program.

phed@Arjuna ~/dosbox]make
make[1]: L/bin/make  all-recursive
make[1]: Entering directory `/Users/phed/dosbox'
...
make[1]: Leaving directory `/Users/phed/dosbox'
phed@Arjuna ~/dosbox]

Next run SandboxInstall to install the program into the Programs-tree

phed@Arjuna ~/dosbox]SandboxInstall dosbox CVS
SandboxInstall: unionfs is available.  Using UnionSandbox!
SandboxInstall: Installing DOSBox...
...
SandboxInstall: Postprocessing Sandbox
phed@Arjuna ~/dosbox]

And at last, run SymlinkProgram to link it into the LHS tree.

phed@Arjuna ~/dosbox]SymlinkProgram DOSBox CVS
SymlinkProgram: Symlinking DOSBox CVS.
...
SymlinkProgram: Done.
phed@Arjuna ~-->dosbox]

And then we’re done. Enjoy!

Installing Packages from the LiveCD

After installing GoboLinux and booting from the hard disk, you may want to choose software packages from the Live CD to install. To do so, you must mount the squashfs file that contains the image from the Live CD system.

To do that, first mount the CD then mount the desired GoboLinux squashfs file:

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

Now, you can use InstallPackage to install software from the Program/ directory of the Live-CD:

InstallPackage /Mount/SquashFS/Programs/Inkscape

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

umount /Mount/SquashFS

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

InstallPackage --batch Gimp

-or-

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

Filesystem Virtualization with Runner

Runner is a utility for launching programs under GoboLinux that ensures that the filesystem view of a process will match its dependencies. In other words, Runner eliminates the possibility of library conflicts when running an executable.

Runner is a filesystem virtualization tool that sets up a constrained view of /System/Index for a process based on the executable program’s Dependencies file. It is run as a wrapper, e.g. Runner SomeApp.

Runner builds a custom mount table for the process, like container tools do, but without duplicating files. It dynamically picks the correct parts of your /Programs tree. This approach is feasible in GoboLinux due to way programs are each confined to their own subdirectories.

Preparing the filesystem view

All you have to do is to make sure the dependencies of the program you want to run are correctly listed under the program’s Resources directory - more specifically, in the Dependencies file at /Programs/Name/Version/Resources/Dependencies. You may list program names (e.g., LibPNG), specify a particular version (as in LibPNG 1.4.4) or even let Runner pick the best version given a certain range (e.g., LibPNG >= 1.4.0, < 1.5.0).

Most likely, the program you want to run will already have a sane Dependencies file - every binary package we distribute will have one, just like every compilation recipe do.

The Compile tool

Compile makes use of Runner to control the environment for building software packages. When you type Compile Foo, Compile fetches the recipe for Foo and passes both the Dependencies and BuildDependencies files of that recipe to Runner. This ensure that the right versions of the libraries, headers, and executables needed by that package will be mapped onto /System/Index.

Spawning an application with Runner

For regular GoboLinux packages, simply type Runner application_name. Runner will figure from which entry under /Programs application_name comes from, and will create a custom filesystem view for that application by overlaying its dependencies over /System/Index.

For non-regular GoboLinux packages, such as third-party executables downloaded on your home directory, you can hand-craft a Dependencies file and then provide that file to Runner, as in Runner -d MyDependenciesFile ./third_party_app.

Multi-arch setups

Running a 32-bit application on a 64-bit distro is no different with Runner. Provided that you have the 32-bit dependencies installed under /Programs (such as Glibc/2.18-i686 and Bash/3.1-i686), the Dependencies file of your program simply needs to state the versions of the 32-bit packages it relies on. Afterwards, simply type Runner <application_name> and you are all set.

Sandbox Install

If I wanted to run make my self, what would I need to do to sandbox it?

This is how its done.

tar xvzf Foo.tar.gz
cd Foo
PrepareProgram Foo 1.0 -- --enable-crazy-feature-x
make
PrepareProgram -t Foo 1.0
SandboxInstall Foo 1.0
SymlinkProgram Foo 1.0

See also: How To’s → Manual Compile