The main task of a Linux distribution is to keep track of and organize the
programs in your computer, so that they work properly. GoboLinux is no different
from the others in this goal, but it adopts a fundamentally different approach
in solving this problem.
Instead of scattering the files of programs around,
following the
decades-old conventions
of ancient UNIX systems, and then adding a layer of control (a “package
manager”) to try to give order to chaos, in GoboLinux we organize the files that
comprise the programs in an ordered way in the first place.
In GoboLinux, every program lives in its own subdirectory. Under the top level
directory /Programs; e.g you’ll find Xorg 7.0 at /Programs/Xorg/7.0, and
ping at /Programs/Netkit-Base/0.17/bin/ping. To see what programs are
installed in the system, all you need to do is look in the /Programs
directory:
ls /Programs
For each category of files, there is a directory under /System/Index grouping
files from each application as symbolic links: bin, lib, libexec,
include, share, and man. For compatibility, each “legacy” UNIX directory
is a link to a corresponding category. Therefore, /bin, /sbin, /usr/bin,
/usr/local/bin (and so on) are all symlinks to entries under /System/Index.
In short, what we have is a database-less package management system: the
directory structure itself organizes the system. Wasn’t that its original
purpose, after all? Each program directory (for example, /Programs/KDE) holds
version directories (/Programs/KDE/3.4, /Programs/KDE/3.4.2), and a
version-neutral directory for settings (/Programs/KDE/Settings), to keep files
that would normally be in /etc.
Keeping two or more versions of a library is
trivial: upgrading LibPNG to 1.2.8 means adding /Programs/LibPNG/1.2.8, but
does not automatically imply that LibPNG 1.2.7 is removed. This way, if a
program depends on the previous version, it won’t break. As you can see,
GoboLinux gives you a finer control of what is and isn’t in the system.
Historical tidbit: When most distributions switched to GCC 3 they released a
new major version, mostly incompatible with previous ones. In contrast, when the
006 series of GoboLinux adopted GCC 3, compatibility was preserved by simply
keeping old versions of libraries alongside the new ones, while they were
gradually phased out. No “compat” packages were needed.
GoboLinux has a directory structure different from most other Linux
distributions. In GoboLinux, all files for a program, including executables,
headers and libraries, are installed below a single directory that belongs to
that program.
So the ping utility might reside in
/Programs/Netkit-Base/0.17/bin/ping
and libpng.so.3 in
/Programs/LibPNG/1.2.5/lib/libpng.so.3
To be visible to other software, these files are symlinked into standard
locations in the new directory hierarchy under /System/Index:
As a result, most things just work. For example, GoboLinux will correctly
dispatch scripts with shebang lines such as #!/usr/bin/env perl or
#!/usr/bin/python to the proper interpreter.
This architecture —installing each program under its own directory, and making
executables, headers other resources available via symlinks— has significant
advantages:
Unfortunately, not all programs have the flexibility to be installed anywhere.
Occasionally, hardcoded paths creep in even in programs that belong to userland,
and should, at least theoretically, allow themselves to be installed inside,
say, a user’s home directory.
As much as we’d like to see this done in the long term, patching all
applications is not an option. For this reason, GoboLinux keeps, as stated
earlier, a legacy tree where all usual Unix paths are mapped to GoboLinux
equivalents. That way, if a Makefile looks for
/usr/X11R6/include/X11/Xaw3d/XawInit.h, it will find it, although it is really
at /Programs/Xaw3d/1.5/include/X11/Xaw3d/XawInit.h, where it belongs. When two
applications have a directory entry with the same name, the GoboLinux scripts
recursively expand them. Both Xorg and Xaw3d have X11 under include. A
directory /System/Index/include/X11 is created automatically, holding links
from both X11 directories.
Another interesting feature is that the GoboLinux scripts execute make install
using a special user id that only has write permissions inside the program’s
source directories and the program’s entry under /Programs. This way, files
can’t “escape” from the GoboLinux hierarchy and slip a directory into the legacy
tree.
A detail that might surprise you at first is that when you look at the root
directory (with ls or graphical tools), you don’t see the legacy directories,
even though you can cd into them. They are certainly there — they are just
kept hidden using GoboHide, a kernel modification
designed to conceal the legacy tree from the usual system view. (GoboHide is of
course optional — GoboLinux works just as well using standard Linux kernels.)
Influences and roots
As you read this, you have probably found many familiar concepts (not to mention
directory names). GoboLinux has clearly found inspiration in other operating
systems, like NeXT, BeOS and AtheOS, but it was the notion that they build
“something different” using an existing Unix base (be it using a BSD foundation
as in macOS, or using GNU tools as in AtheOS) was the most important influence
of all. There are several other projects, in various stages of development, that
use the Linux kernel as a foundation and feature alternative directory trees.
Interestingly, most of them are clones or heavily inspired by a specific
proprietary operating system. (At different points in time, we’ve seen clones of
RiscOS, NeXT, BeOS.)
GoboLinux, on the other hand, is not a clone of anything else. It uses standard
Linux desktop software. We believe that the well-organized directory structure
makes it a good testbed for new ideas — possibilities are wide open (see the
forum and moreso the mailing list for discussions, and to a lesser extent the
IRC channel #gobolinux on libera.chat).
Differences between GoboLinux and a traditional Linux system
What follows is not a thorough description of GoboLinux, but a quick cheat-sheet
of facts that are good to know when you are getting acquainted to the system.
In the GoboLinux hierarchy, files are grouped by their functional category
(executables, libraries, and so on). There are links at the classic
directories you are used to (/bin, /usr/bin, and so on), but remember
that they all point to the same place. This is a huge advantage, as it
means, for example, that you’ll never have to search for a library
throughout your filesystem again – it will always be in /lib (and in
/usr/lib, because they point to the same place! – no worries about
compatibility).
There are symbolic links relating most of the usual UNIX directories to the
GoboLinux tree. Therefore, you will find directories such as /etc,
/var/log and /usr/bin in the expected places. However, some directories,
such as the users’ directories, didn’t need to be linked to their “legacy”
locations. This way, for a given user called “joe”, you’ll have, instead of
/home/joe, /Users/joe. Notice also that the superuser’s directory is no
different than the ones from the other users, so, root’s directory is at
/Users/root. Mount points are under /Mount, not /mnt.
Another major difference between GoboLinux and most Linux distributions is
that it does not use a BSD nor a System V initialization procedure. Instead,
it has its own. At /System/Settings/BootScripts you will find a few files
that command the entire boot procedure: BootUp and Shutdown run at system
boot and shutdown, respectively; you can define custom “runlevel” scripts to
define different ways you want your system to be initialized (say, Single
and Multi for single and multi-user, Graphical for boot into graphic mode,
etc.) and control that from the boot loader menu. The
/System/Settings/BootOptions file separate site-specific settings from the
rest of the scripts. You can also find a library of application specific
tasks at /System/Tasks that can be used during boot (those are installed
by the apps).
For a better overview of how it looks and feels right, nothing beats giving the
LiveCD a spin. You’ll be running a full GoboLinux system without having to
install anything.
Just flash a USB-Drive and give it a go !!
GoboLinux Filesystem Hierarchy
Here is an overview of the GoboLinux filesystem tree. The legacy folders (on the
“:” part of the tree) are links to the corresponding GoboLinux folders. The
legacy folders are excluded from default directory view by
GoboHide.
/
|-- Data - for resources belonging to the system and to individual programs
| |-- Compile - sources, recipes and other files used by the Compile tool
| | |-- Archives
| | |-- LocalRecipes
| | |-- PackedRecipes
| | |-- Recipes
| | `-- Sources
| `-- Variable - for spool files, log files, temporary files, etc.
| |-- cache
| |-- empty
| |-- lib
| |-- lock
| |-- log
| |-- run
| |-- spool
| `-- tmp
|-- Mount - mountpoints for filesystems
|-- Programs - where programs (with all their files) are installed
|-- System
| |-- Aliens - files managed by programming language package managers
| |-- Environment - links to program files declaring environment variables
| |-- Index - links to files in each program's
| | |-- bin + bin/ and sbin/ directories
| | |-- include + include/ directory
| | |-- lib + lib/ directory
| | |-- libexec + libexec/ directory
| | `-- share + share/ directory
| | |-- consolefonts
| | |-- fonts
| | `-- man
| | |-- info + info/ directory
| | `-- man{1-9} + man{1-9}/ directories
| |-- Kernel
| | |-- Boot - kernel images, config files and programs needed to boot
| | |-- Devices - device files (managed by Udev).
| | |-- Modules - loadable kernel modules (device drivers)
| | |-- Objects - a view of the kernel's device tree
| | `-- Status - kernel status files (belonging to the /proc filesystem)
| |-- Settings - system config files and links to files in program's Settings/ directories.
| | `-- BootScripts - scripts used for boot, symlink to /Programs/BootScripts/Settings/BootScripts/
| `-- Tasks - links to programs' boot tasks (from their Resources/Tasks/ directory)
|-- Users - contains users' home directories
:
:
:-- etc -> System/Settings
:-- dev -> System/Kernel/Devices
:-- sys -> System/Kernel/Objects
:-- proc -> System/Kernel/Status
:-- var -> System/Variable
:-- tmp -> System/Variable/tmp
:-- sbin -> System/Index/bin
:-- bin -> System/Index/bin
:-- lib -> System/Index/lib
:-- lib64 -> System/Index/lib
`-- usr
|-- X11R6 -> .
|-- local -> .
|-- bin -> ../System/Index/bin
|-- sbin -> ../System/Index/bin
|-- include -> ../System/Index/include
|-- lib -> ../System/Index/lib
|-- lib64 -> ../System/Index/lib
|-- libexec -> ../System/Index/libexec
`-- share -> ../System/Index/share
System Index
Compiled programs in C and C++ typically have a lib/ directory and often also
a bin/ directory.
On GoboLinux, these will be symlinked into /System/Index such as for ping:
Installer is a program included on the GoboLinux Live-ISO that installs
GoboLinux to your hard drive.
It takes care of basic configuration, package selection, and boot
loader setup. It can be run from the command line or via the window manager
menu.
Graphical Install
The GoboLinux Live-ISO supports a complete graphical display environment.
In most cases, the X server automatically detects the keyboard and display
hardware, so you can start the graphical mode by typing:
startx
Clicking on the top-left icon brings up a menu. Look under System Tools, select
“Install GoboLinux”, follow the instructions.
Console install
Type Installer in the console. Note the capital “i”. (GoboLinux utility
scripts are generally named with an initial capital and follow the CamelCase
convention.)
QEMU provides a networking stack so that the guest OS running on this virtual
machine can access the internet, or ssh to the host.
The only extra setup needed is to run Gobo’s DHCP client inside the guest.
dhcpcd
By default QEMU acts as a firewall and does not permit any incoming traffic. It
also doesn’t support protocols other than TCP and UDP. This means that ping and
other ICMP utilities won’t work.
The script has some library dependencies. The most convenient way to install
them (and any CPAN modules) is to use cpanminus (cpanm). So install
cpanminus, then the dependencies:
The script follows below. Edit the QEMU options to your liking, put the script
in somewhere in your $PATH, and make it executable with something like
chmod a+x ~/bin/qemust.
#!/usr/bin/env perluse strict;
use warnings;
# qemust - start QEMUuse5.012;
use Getopt::Long::Descriptive;
my ($opt, $usage) = describe_options(
'%c %o',
[ 'iso=s', "ISO file to boot" ],
[ 'image=s',"OS disk image file" ],
[ 'help', "print usage message and exit" ],
[ 'n', "print QEMU startup command and exit" ],
);
print($usage->text), exit if$opt->{help} or ! keys %$opt;
my$boot_drive = $opt->{iso} ? 'd' : 'c';
my@cmd = grep{! /^\s*$/} map{s/\s*#.*$//; $_} split "\n",<<"CMD";
sudo # run as root
qemu-system-x86_64 # for 64-bit CPUs
-enable-kvm # faster virtualization
-show-cursor #
-boot $boot_drive # boot from DVD/CDROM if present
-m 768 # use memory 768MB
-cpu host # same CPU model as host
-daemonize # avoid race conditions when QEMU started by external program
-vga std # probably -vga vmware would work, too
-soundhw ac97 # typical soundcard, -soundhw hda should also work
-rtc base=utc # timer related
-usb # enable USB driver
-usbdevice tablet # so QEMU can report mouse position without grabbing mouse
-device usb-mouse #
-clock unix #
CMDpush @cmd, "-cdrom $opt->{iso}"if$opt->{iso};
push @cmd, "-hda $opt->{image}"if$opt->{image};
my$cmd = join " \\\n",@cmd;
say $cmd;
system($cmd) unless$opt->{n};
__END__
Running under VirtualBox
Note
This article has been written for an older GoboLinux
release, and is potentially out of date!!
Setting up VirtualBox guest additions
VirtualBox requires its own graphics drivers in order to perform advanced
features such as smart mouse sharing and running at a window-dependent full
resolution.
These drivers can be built using the “Guest Additions” ISO image included with
VirtualBox.
The catch is that we are already using the virtual CD drive from VirtualBox to
run the ISO, so we need to add a second one. With the virtual machine shut down,
right-click the image, then at the Storage pane, add a second optical drive, and
insert the VBoxGuestAdditions.iso file that should be somewhere in your
VirtualBox installation:
Then, boot GoboLinux normally in VirtalBox, and do the following:
mount /dev/sr1 /Mount/CD-ROM
cd /Mount/CD-ROM
./VBoxLinuxAdditions.run
udevadm trigger
When you run udevadm trigger the drivers should be loaded, and the console
will change resolution immediately. (It will also lose the nice-looking
GoboLinux font: to reload it, type setfont lode-2.0-lat1u-16.)
Now, you can start Xorg normally with:
startx
If you want to resize your VirtualBox window, make sure “Auto-resize guest
display” is turned on in the VirtualBox “Machine” menu, then, after resizing the
VirtualBox window, type in the GoboLinux terminal the following
xrandr --output VGA-0 --preferred
This will resize the desktop to match your window size.
Note that this installation of the VirtualBox guest additions will only last for
the current Live-CD session. If you install GoboLinux into a VirtualBox virtual
hard drive, you will have to do the same again.
Running under GNOME Boxes
GNOME Boxes is a new virtual machine manager and remote desktop manager powered
by QEMU, KVM, and libvirt virtualisation technologies. Running Gobolinux under
GNOME Boxes is quite easy, even more so than under Virtualbox.
Setup Instructions
Create a new Virtual Machine by clicking “New” in the top left corner.
Click “Select a file”.
Select the Gobolinux LiveCD ISO file.
Boxes will be ready to create a virtual machine with 2GB of RAM and 21.5GB of
storage. If that is sufficient, click “Create”.
Otherwise you can click “Customize” and adjust the sliders for RAM and
storage respectively, then click the back arrow.
The LiveCD session will then start. Continue normal installation procedures.
Remember to eject the LiveCD prior to reboot by going to the top right menu
and clicking “Properties” -> “Devices & Shares” and then clicking “Remove”
beside the CD/DVD section.
Installing SPICE
Spice allows for integration with the host system including setting native
resolutions, file transfers, clipboard support etc.
Compile SPICE-VDAgent
Run StartTask Spice-VDAgent after login
Run spice-vdagent
Run xrandr --output Virtual-0 --preferred to update the resolution
Installing to external storage devices
Note
This article has been written for an older GoboLinux
release and is potentially out of date!!
GoboLinux 016 comes with two installation modes: UEFI and BIOS-compatibility
mode. Depending on how your computer firmware is configured you may need to
follow one or another recipe below.
BIOS-compatibility mode
Ensure that your external disk has been configured with a MSDOS partition
table. You need to have at least one Linux partition (e.g., ext4), with the
BOOT flag set.
You can then proceed with the installation of GoboLinux by selecting that Linux
partition as install target and by enabling the installation of the bootloader
on the master boot record (MBR) of that disk.
UEFI mode
Ensure that your external disk has been configured with a GPT partition
table. You need to have at least one Linux partition (e.g., ext4) and a FAT
(32/16/12) partition which is where the UEFI application embedding the GRUB
bootloader will be stored. The FAT partition needs to have both the ESP and
BOOT flags set. If you are using GParted, that FAT partition will be
automatically formatted by the tool. If you are not, then make sure to invoke
mkfs.msdos to format it yourself.
Once the partitioning is arranged, you can proceed with the installation of Gobo
by selecting the Linux partition as system install target and by selecting the
FAT partition (also called EFI System Partition) as bootloader install target.
Troubleshooting
Unable to mount root fs
Both USB-Storage and UAS (USB-Attached-SCSI) drivers are built into the kernel.
However, at times the kernel may not have time to discover the partitions on
your external disk and may fail to mount the root filesystem. This particular
problem can be fixed by adding the rootwait parameter to the kernel command
line.
For BIOS-compatibility mode:
Mount your system partition using the LiveCD under /Mount/GoboLinux
Edit the file at /Mount/GoboLinux/System/Kernel/Boot/grub/grub.cfg. Look
for the lines starting with linux /System/Kernel/Boot/kernel-4.8.2-Gobo and
append the word rootwait to the very end of those lines
Unmount the partition under /Mount/GoboLinux and reboot.
For UEFI mode:
Mount your boot partition (the one with a FAT filesystem) using the LiveCD
under /Mount/GoboLinux
Edit the file at /Mount/GoboLinux/EFI/BOOT/grub-efi.cfg. Look for the lines
starting with linux /System/Kernel/Boot/kernel-4.8.2-Gobo and append the
word rootwait to the very end of those lines
Regenerate the UEFI application. This is a large command, so it’s better to
just copy+paste it.
You will be prompted to update some settings. Select “U” on each prompt.
Now you can proceed the installation of GoboLinux 017.01 via our Installer.
Installed System
Update of Compile and Scripts tools
Compile and Scripts are always evolving. Make sure to update your copies by
running the following commands after you boot into your installed system for the
first time:
Some problems have been reported by our users and are currently being fixed by
our team. They are:
Copy-and-paste does not work out of the box from a VM. Compiling
spice-vdagent and loading its daemon should fix that.
Sometimes when trying to Compile an already-installed Program, the build
process will fail (see
Compile bug 51). Sometimes
this can be worked around by first manually doing a
RemoveProgram <failing program> before re-attempting to Compile it. Note
that it is generally a Bad Idea™ to try to RemoveProgram, say,
Python3 like this as it will break Compile.
ContributePackage is not working – use
ContributeRecipe instead.
With Compile, GoboLinux build utility, software sources can be downloaded,
compiled and installed in a single step. An example will follow next.
In order to install irssi, a text-based IRC client from the command line,
you would type the following instruction:
Compile irssi
Depending on the speed of your computer, internet connection and what packages
you have installed, Irssi should download and install in a few minutes.
Compile manages the build process using GoboLinux recipes. Each recipe contains
a list of build directives and supplemental control files for compiling a
particular software library.
Finding recipes
Typically, you can just try the name of the recipe you want from the command
line. There is also an online recipe viewer,
listing the most recently uploaded recipes first.
Command-line options
Compile has a number of command-line options, which are listed
here. The following are especially useful.
When using the --batch or -b automatically attempts to process all
dependencies of the requested program.
Separating download and compile phases
The next two options are useful when working with intermittent internet access,
or if you’d like to run your compiling jobs at night when you’re asleep.
Calling Compile with the --no-build flag downloads sources only.
Later, in the event that you wish to use the --no-web flag, this will direct
Compile to search to your system’s own download cache and build the sources
found there instead. This commandline switch is obviously very useful if you do
not have a working internet connection for the time being.
In general it is recommended to always use the latest stable version of
Compile. Compile is very important to GoboLinux so if
there is any problem in it, it is normally fixed very quickly.
Binary packages
Warning
We do not maintain a binary package repository at this time! |
Please build your packages from source using Compile!
Binary packages in GoboLinux are precompiled software packages built for the
GoboLinux directory tree and made available through the GoboLinux software
repository (recipe store). Since these packages are already compiled, you can
save the many hours needed to build larger applications. On the other hand, with
binary packages you don’t have the ability to set compile flags for optimization
or specific architectures.
Installing packages
InstallPackage is the GoboLinux script for
installing binary packages. If you want
InstallPackage to look for the most recent Gimp
package available, you can run
InstallPackage Gimp
The script will check if the package is available in the GoboLinux repositories.
(See /System/Settings/GetAvailable.conf for the specific URLs scanned. You may
add your own repositories if you desire.)
If you want to select a specific version, you can pass it as the second
parameter:
InstallPackage Gimp 2.8.18
If you downloaded the package and want to install it, run:
InstallPackage Gimp--2.8.18--i686.tar.bz2
The script normally runs interactively, asking about each dependency of the
requested package before installing it. You can avoid these queries by adding
the --batch or -b flag. This is particularly useful with large packages such
as Gimp or Xorg, which have many dependencies.
InstallPackage -b Gimp
Dependencies
InstallPackage will warn you if dependencies of a package you are trying to
install are unavailable and ask if you want to continue. This is valuable,
because some software may still work satisfactorily even if a particular plug-in
or other dependency is missing.
In GoboLinux, all binary packages (as well as all user-compiled software) is
installed under /Programs in a “program directory” provided for each version
of each application, for example:
/Programs/Gimp/2.8.18
When compiling software under GoboLinux the installation target directories such
as bin/, lib/, and etc/ that are required for a typical program are placed
inside the program directory.
With this self-contained directory structure, all that is needed to generate a
binary package is to make a tarball of the program directory, copy over the
Resources/ directory from the Compile recipe, and generate a few additional
files, which are also placed under Resources/.
Before creating a package, be careful to vet the contents of the program’s
Settings/ directory to ensure that it does not include personal information.
A package submitted for inclusion in the GoboLinux packages repository must have
sensible default settings, honoring the application defaults if possible.
The CreatePackage command
In order to create a package, run the
CreatePackage utility with the package name as a
parameter. For example,
CreatePackage rxvt
will create a binary package in the current working directory.
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.
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:
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.
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.
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
GlibcNvidia
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:
Compile.conf is the file where you can configure the various paths and URLs used
by Compile.
It is stored at /Programs/Compile/Settings/Compile/Compile.conf – which, once
installed, has a link at /System/Settings/Compile/Compile.conf (if you’re used
to the GoboLinux tree, you should know by now that this is the same as
/etc/Compile/Compile.conf).
These are the usual contents of the file:
Your name here so that credit is added to recipes.
compileRecipeAuthor="Paul McCartney"# example only! change the name (unless of course, you're Paul ;) )
The standard locations for your local Compile files.
Some of the main free software repositories are treated especially: recipes use
these variables in their url declarations, so that you can pick your favorite
mirror without having to edit recipes one by one:
A variable to set the make command called by Compile. ColorMake provides the
highlighting that GoboLinux has by default:
compileMakeCommand="ColorMake"
Options to use with the make command. This can be used to run multiple threads
in parallel on different CPUs or for other customisation:
compileMakeOptions="-j2"
Environment variables
Some environment variables influence the behavior of some GoboLinux tools. You
may want to set them. Just remember that GoboLinux uses zsh (not bash) as its
default shell, so you should edit .zshrc (not .bashrc). Zsh is a
Bourne-style shell, though, so the syntax you’re used to is still valid.
Of course, if you really prefer bash (though we really recommend giving zsh a
try!), you can change your default shell using the chsh command. See the
chsh man page for details.
The $EDITOR variable should be set to your favorite text editor. Whenever a
GoboLinux tool needs to run an editor, it will run the one indicated in this
variable (in fact, this is not a GoboLinux variable, several programs use it).
GetAvailable
Warning
We do not maintain a binary package repository at this time! |
Please build your packages from source using Compile!
GetAvailable.conf is the file where you can configure paths and URLs used to
locate binary packages.
It is stored at /Programs/Scripts/Settings/Scripts/GetAvailable.conf – which,
once installed, has a link at /System/Settings/Scripts/GetAvailable.conf (if
you’re used to the GoboLinux tree, you should know by now that this is the same
as /etc/Scripts/GetAvailable.conf).
These are the usual contents of the file:
The timeout (in seconds) when trying to fetch the packages list from a sever.
timeout=15
The paths from which local packages will be automatically be found. Notice that
both compressed (e.g. /Depot/Packages/Qt--4.0.0--i686.tar.bz2) and
uncompressed (e.g. /Mount/SquashFS/Programs/Qt/4.0.0) packages can be matched.
The URLS from which lists of tracked versions will be retrieved. A tracked
version is a program version that actually may not have a correspondent Recipe
or binary package, but that is already made available by the program developers
The Linux kernel differs from standard packages. It has nothing to be linked
against the legacy tree: no libraries, no binaries, no headers, no manuals or
info pages. Moreover, there are many things on a regular system which are very
tied to the kernel itself, such as the proc and sys filesystems, the device
nodes and the boot loader files.
These characteristics led to the creation of a special directory for the kernel,
called /System/Kernel. This tree is organized in the following way:
/System/Kernel/Boot - Bootloader files, including the kernel image
/System/Kernel/Devices - Device nodes, populated by Udev + Hotplug
/System/Kernel/Modules - Kernel modules
/System/Kernel/Objects - Sysfs, providing information gathered from Linux
2.6
/System/Kernel/Status - The mounted proc filesystem
Installing a kernel
Thanks to Compile, installing a new kernel is pretty straightforward on
GoboLinux. The Linux recipe takes into account the existence of a file called
config.gz inside /System/Kernel/Status. This file contains the current
configuration for the running kernel, and is used thereby to feed the new kernel
options.
In short, running Compile Linux will fetch the latest available recipe
(which already contains GoboLinux optional patches). After doing that, the
kernel itself is automatically downloaded, patched and filled with the current
configuration, taken from config.gz.
The menuconfig entry then appears, and allows for the user to modify their
kernel options. Just selecting Exit and telling the script to save the changes
will finish the user’s interaction with the Linux kernel compilation. After
completed, a new entry will appear under
/System/Kernel/Modules/$KERNEL_RELEASE, and the new bzImage and System.map
files will get installed under /System/Kernel/Boot.
The old bzImage and System.map files aren’t overwritten, though. They’re just
symlinks to the current kernel image, and this guarantees that if something goes
wrong, a rollback can be done by simply modifying the kernel image at the GRUB’s
bootloader prompt, and later by reverting the symlink’s target to the previous
release.
To install a kernel which is newer than the available recipe, or one other than
vanilla, you may use NewVersion.
If you already have a kernel downloaded, or have a special source package, you
may place it in /Data/Compile/Archives.
Use
NewVersion Linux <Version> https://kernel.org/pub/linux/kernel/v6.12/<your-archive-name>
to create a recipe. Using a fake URL is all right if you don’t intend to
distribute the recipe.
Place any custom patches you need to apply into the
/Data/Compile/LocalRecipes/Linux/<Version> directory.
Then Compile as usual.
Kernel patches
The Linux recipe comes with a few patches in order to improve the user’s
experience with the system. The patchset includes, but is not restricted to, the
following modifications:
GoboHide: allows the legacy tree to be hidden from
userspace applications
SquashFS: A compressed filesystem which gets uncompressed on demand. This
filesystem is currently used on the GoboLinux ISO, and so it’s interesting
to have it in order to get the CD contents easily accessible through the
mount command
