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 , 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.