Subsections of Package Management
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 programs
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.
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
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