Removing programs

In GoboLinux, all programs, whether binary packages or user-compiled software, are installed into a single directory under the /Programs hierarchy, such as, for instance, gimp:

/Programs/Gimp/2.8.18

Removing this program can be, in theory, as simple as:

rm -rf Gimp/2.8.18 

But since this leaves behind dangling symlinks, GoboLinux offers the RemoveProgram utility, which removes the program and all links pointing to its files in /System/Index.

RemoveProgram Gimp 2.8.18

Sometimes you may want to “turn off” a program temporarily, without erasing it from your hard disk. In other words, you want to remove program’s executables from the execution path, and remove libraries and headers from the lookup path.

In GoboLinux, this can be accomplished by removing the associated symlinks for /System/Index. The DisableProgram script facilitates this:

DisableProgram gimp 2.1.18

The version parameter given here, in this case 2.1.18, is optional. If it is not provided, the Current link is used to determine the program version to disable. Also note that the program name is case insensitive, but it appears to be simpler to use a downcased variant - easier to type at the least.

To re-enable the program, all you need to do is recreate the symbolic links:

SymlinkProgram gimp 2.1.18

Maintaining symlinks

GoboLinux has a script called RemoveBroken. that removes dangling symlinks from /System/Index tree. It can be useful to run after manipulating directories under /Programs.

RemoveBroken takes a list of files, and removes those that are dangling symlinks. If no arguments are provided, the script takes filenames from standard input (typically through a pipe).

The usual procedure to clean up dangling links, is

cd /System/Index
find | RemoveBroken

Understanding and Maintaining system indices

The two main parts of GoboLinux are /Programs and /System. If you stick to using InstallPackage and Compile, these two parts will be implicitly kept in sync by SymlinkProgram. But a lot of power lies in the fact that you can tune how these two worlds interact.

Program entries under /Programs feature a Current symlink pointing to a specific version that is “active” in the system. This Current version is taken as the default version when you don’t specify a version in scripts, and the link is updated when you install a new version with InstallPackage or Compile.

That doesn’t mean that you can only have one version linked into the system: you can have files of multiple versions show up in /Programs. In fact, when you install a new version with InstallPackage but keep the old version in /Programs, files for which there’s no version with the same name in the new package are still linked – this is especially useful for libraries.

For example, say program Foo 1.0 looks like this:

/Programs/Foo/1.0/bin/foo
/Programs/Foo/1.0/include/foo.h
/Programs/Foo/1.0/lib/libfoo.so.1
/Programs/Foo/1.0/lib/libfoo.so -> libfoo.so.1

Now, say, you install a new version, 2.0, which looks like this:

/Programs/Foo/2.0/bin/foo
/Programs/Foo/2.0/include/foo.h
/Programs/Foo/2.0/lib/libfoo.so.2
/Programs/Foo/2.0/lib/libfoo.so -> libfoo.so.2

The default behavior of SymlinkProgram is to replace symlinks under /Programs that belong to a different version of the same program. So, now, we’ll have the following links related to Foo under system:

/System/Index/bin/foo -> /Programs/Foo/2.0/bin/foo
/System/Index/include/foo.h -> /Programs/Foo/2.0/include/foo.h
/System/Index/lib/libfoo.so.2 -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so.1 -> /Programs/Foo/1.0/lib/libfoo.so.1

So, now, when you run foo, it will fetch version 2.0 of the program through your system $PATH (which looks at /System/Index/bin). But, as you can see, libfoo.so.1 is still there. This way, if you have other programs installed in the system that are linked specifically to version 1 of the libfoo library will continue working.

This means you won’t have the old problem “I upgraded package Foo and now my other apps are broken”. Of course, you can still break things when you remove a version which other programs depend in (or if buggy programs link to a version independent name of a library (libfoo.so) but depend on features of a specific version).

Besides SymlinkProgram (see section “Compiling manually” and its reference entry for details on it), there are other scripts that give you more control over what is linked in the system and what is not.

With DisableProgram, you can remove from /System all links that refer to a specific version of a program, effectively “turning it off” – it is as if it were not present in the system.

With RemoveProgram, you can remove a program from /Programs and its references from /System in a single step.

See Removing programs for more details.

Updating packages

Overview

Use the UpdateRecipes command to refresh your local cache of the GoboLinux recipe store.

You can query available updates using the utilities SuggestUpdates and SuggestDuplicates. The output of each of these commands is suitable for piping into commands.

The FindPackage and GetAvailable commands may also be useful.

Example Update Process

Keep in mind that most operations that change the file-system state in Gobo require super user privileges:

Ensure that Scripts are up to date

cd /Programs/Scripts/Current
sudo git pull && sudo UpdateSettings --auto Scripts && sudo make

Ensure that Compile is up to date

cd /Programs/Compile/Current
sudo git pull && sudo UpdateSettings --auto Compile

UpdateRecipes - Update local copy of recipe store

cd /Data/Compile/Recipes
sudo UpdateRecipes

SuggestUpdates - List packages with an update available

cd /Data/Compile/Recipes
SuggestUpdates

Install updates

Currently, there is no way to update packages automatically. This used to be done with the Freshen script, which is currently not in working order.

Updates thus need to be installed manually via InstallPackage or Compile as appropriate.

Dependencies blacklist

Configuring Dependencies

Today there are many programs implementing a given feature in different ways. One such example is the OpenGL API, with implementations floating in packages such as Xorg, MesaLib and Nvidia. However, not every user owns a Nvidia card, and here comes a problem: how should one mask Nvidia from the automated Dependencies list generated after creating a recipe? This problem is now fixed with a configurable file called /Programs/Scripts/Settings/Scripts/Dependencies.blacklist.

Dependencies.blacklist

This file allows one to specify packages that should not appear in the Dependencies file after creating a new recipe. Its format is pretty simple: one package per line, without the need to specify its version.

A Dependencies.blacklist example

The following example blacklists the packages Glibc and Nvidia. Comments and blank lines are ignored by the parser, so it’s ok to include them.

# Dependencies.blacklist is documented in detail at
#  http://wiki.gobolinux.org/Dependencies

Glibc
Nvidia

Note: presently blacklisting specific versions is not supported, but the same behaviour can be achieved by creating an empty directory in the /Programs directory. For example, to blacklist GCC version 4.1.2 you may:

mkdir /Programs/GCC/4.1.2