The basic idea behind the GoboLinux hierarchy is to combine ideas from the previously presented operating systems and the link system introduced by Depot, creating a new hierarchy that maintains total compatibility with the UNIX tree. Like in Depot, each program (Gimp, Fileutils, Glibc, Qt, etc.) is installed in its entirety inside a separate directory. Inside this directory, standard UNIX directories are typically created, containing files that in the traditional UNIX directory tree would be copied to /usr/bin (or /bin), /usr/sbin (or /sbin), /usr/lib (or /lib), and so on.
For this purpose, a /Programs directory was estabilished, containing a subdirectory for each installed program. Each of those subdirectories has, on its turn, a subdirectory for each version of the specific program, and a link labeled Current pointing to the currently used version. Each program also has a Settings directory storing the program's configuration files (which would be normally stored at /etc). Notice that this directory is unique for all versions of the program. This design choice eases the version control, since the personal configurations are preserved in the event of an upgrade or downgrade.
Installation of programs from source is made through scripts. In the case of programs with configuration files generated using GNU autoconf (which is the majority of free software packages) the script uses the -prefix parameter to define the destination of the files being installed. For example, when installing the Qt library, version 2.3.2, the command configure -prefix=/Programs/Qt/2.3.3 is automatically executed, and the required directories are created. For programs that do not provide this parameter in their configuration files, the configure script (or the Makefiles themselves) will be adjusted, automatically, through scripts that attempt to replace the paths contained in the file; or, in a few cases, manually.
Once a new version of a program is installed, links are created from
each file in the application at directories that centralize those
links according to file types. For example, /System/Links/Executables
stores links for executable files of all programs (contained in the
bin and sbin directories). This way, all executables
can be called or accessed from a single directory (same happening
to th libraries, headers and manuals / info files). This approach
is different from the ones used by the symbolic link management systems
discussed on Section ![[*]](file:/usr/share/latex2html/icons/crossref.png){kind=icon}
, as the generated links structure
does not reflect the UNIX hierarchy, but a functional categorization
of the links.
Figure describes in greater detail the general
directory hierarchy as proposed. An important treat of this structure
is the nonexistence of a global share directory (programs
can have their own share directories). This decision is explained
by the fact that, even though the share directory permits
sharing of data between different applications, in practice this directory
serves a repository for application-specific files that has no place
on the UNIX hierarchy (such as icons and fonts). This way, we opted
not to have a /System/Links/Shared directory, because the
different share directories of each application have no relation
between them.
Compatibility with the UNIX legacy is obtained through creation of extra links not present in the above diagram, such as /etc -> /System/Settings, /bin -> /System/Links/Executables and /lib -> /System/Links/Libraries, mirroring the GoboLinux tree into the UNIX tree. Unlike previous proposals that attempted to organize the directory tree maintaining historical compatibility, in GoboLinux there is a single point for installation of programs, without a legacy tree in parallel.
