GoboLinux

Le noyau Linux n'est évidemment pas modifié, ce serait un travail bien trop important et instable. Pour fonctionner, GoboLinux utilise des liens symboliques. En réalité, l'arborescence FHS est toujours présente, mais elle est rendue invisible. L'arborescence de GoboLinux coexiste juste à côté de celle-ci. L'arborescence FHS est remplie de liens symboliques qui mènent aux vrais fichiers présents dans l'arborescence de GoboLinux.

On pourrait penser qu'il en résulte une perte de vitesse du système, mais concrètement, ce n'est (pratiquement) pas le cas, la gestion des liens symboliques du noyau Linux étant suffisamment bien programmée.

Les développeurs de GoboLinux ont constaté que cette organisation était même plus performante que la FHS car elle supprime des distinctions empiriques entre des dossiers similaires. Par exemple, les problèmes comme les défauts d'exécution d'un script Console parce qu'un exécutable est dans /bin au lieu d'être dans /usr/bin ou /usr/local/bin sont résolus. Les scripts console plantent ainsi moins souvent que dans d'autres distributions.

Un autre avantage de l'arborescence de GoboLinux est qu'elle permet d'installer plusieurs versions d'un même programme côte à côte, ou plusieurs fois la même version d'un programme. Cela permet de lancer plusieurs fois un même programme en même temps afin d'effectuer des comparatifs de performances.

Il n'existe aucun risque de désynchronisation entre la FHS et l'arborescence de GoboLinux car lorsqu'un lien symbolique pointe sur un fichier qui n'existe pas, il devient un lien mort, donc inactif. Il est possible de supprimer ces liens morts du système avec l'outil "RemoveBroken".

Pour que cette organisation fonctionne, GoboLinux n'est constitué que de 3 éléments. En effet, plus d'éléments rendrait le système trop lourd à maintenir pour le faible nombre de développeurs.

• Les scripts d'installation permettent d'installer le système convenablement.
• Le programme Compile permet d'installer un programme selon l'arborescence de GoboLinux.
  • Il peut être utilisé pour supprimer un programme, dans ce cas les liens de la FHS sont automatiquement supprimés avec.
  • Il est aussi possible de simplement supprimer le dossier du programme pour le désinstaller complètement avec rm -rf. Mais dans ce cas, il reste dans la FHS les liens vers les fichiers du programmes. Ces liens sont alors des liens morts qu'on pourra supprimer avec l'outil appelé "RemoveBroken".
• Une extension du noyau Linux appelée GoboHide, qui permet de masquer ou de démasquer un élément du système, et notamment la FHS.

Tous les autres éléments du système peuvent être remplacés par les éléments les plus récents, depuis le noyau Linux jusqu'à n'importe quel programme.

Sous Linux, il est impossible de masquer un fichier ou un dossier sans le renommer en rajoutant le caractère "." devant (contrairement à Windows qui inclut cela dans les attributs du fichier ou du dossier).

• vlc est un dossier (ou un fichier) non masqué
• .vlc est un dossier (ou un fichier) masqué

Dès lors, il était indispensable de créer un programme permettant de "cacher" les fichiers et dossiers de la FHS, mais sans les renommer.

Ce programme s'appelle GoboHide et il fonctionne très simplement :

• ~] gobohide --help pour afficher l'aide
• ~] gobohide -h ou ~] gobohide --hide pour cacher un fichier ou un dossier
• ~] gobohide -u ou ~] gobohide --unhide pour démasquer un fichier ou un dossier
• ~] gobohide -l ou ~] gobohide --list pour afficher la liste de tous les éléments cachés
• ~] gobohide -version pour afficher la version du programme

La commande "ls" n'affichera pas les éléments masqués par la commande "gobohide". Elle n'affiche que les éléments masqués parce que leur nom commencent par un point ".", seule la commande "gobohide" permet d'afficher les éléments masqués par elle-même.

Bien sûr, les éléments existent toujours, une simple commande Bash peut le confirmer, comme ~] [ -f /etc/fstab ] && echo "Il existe" ou ~] l /etc/zshrc.

Le patch GoboHide est appliqué au noyau Linux dès l'installation. En utilisant le programme Compile pour compiler le noyau, le "recipe" du noyau Linux contient les patches pour activer l'extension GoboHide. En cas de recompilation du noyau sans utiliser le programme Compile, il est nécessaire de réappliquer le patch.

~/KernelSources] patch
-i /path/to/gobohide.patch -p1

Grâce à GoboHide, il est désormais possible de masquer ou démasquer les éléments que l'on souhaite. Gobohide rend donc possible la traduction des éléments de Linux comme sous Windows, par exemple en utilisant ce type de commandes :

$ mkdir /Programmes
$ mount -o bind /Programs /Programmes
$ gobohide -h /Programs

ou

$ mkdir /Utilisateurs
$ mount -o bind /Users /Utilisateurs
$ gobohide -h /Users

Le code source est librement disponible[5].

Le programme Compile est similaire au système de portages de Gentoo[6], lui-même basé sur celui de FreeBSD. Mais ce portage est fait pour être compatible avec l'arborescence FHS, et Compile est capable de l'appliquer à l'arborescence GoboLinux. Compile utilise l'arborescence de GoboLinux comme base de données des programmes installés[7].

Il fut introduit avec la version "011" de GoboLinux. Avant cela, plusieurs discussions portaient sur la possibilité d'adapter le système de Gentoo sur GoboLinux, un projet de SourceForge.net appelé GoboPortage[8]^,[9].

Compile se base sur l'idée que les sources d'un programme ne devraient pas être distribuées selon de multiples formats de paquets spécifiques. En effet, entretenir la compatibilité des paquets comme le font les différentes distributions Linux est une immense perte de temps, et si tous les paquets suivaient les normes Linux, tout serait beaucoup plus simple. L'idée centrale est qu'au final, un programme se réduit toujours à un ensemble de fichiers à installer[10].

Donc le programme Compile se contente de télécharger, décompresser et compiler du code source au format Tarball.

Par exemple, il est possible d'installer un programme au format DEB en le traduisant en RPM avec le logiciel Alien, puis de l'installer avec le logiciel rpm2cpio. rpm2cpio vlc.rpm donne vlc.cpio.gz

gzip -d vlc.cpio.gz
cpio -d -i vlc.cpio
PrepareProgram -t vlc 1.0
mv * /Programs/vlc/1.0
SymlinkProgram vlc 1.0

Compile installe le programme décompressé en utilisant une commande très simple (compile vlc)[11].

Compile se charge de placer le programme dans le dossier /Programs/[Nom du programme]/[Version du programme] et de créer les liens symboliques dans le dossier /System/Index.

Le problème est que dans la pratique, tous les paquets ne vont pas s'installer convenablement en utilisant cette méthode, car tous les paquets Linux ne suivent pas forcément les normes de création des paquets. En effet, il existe des variations mineures dans la construction des paquets, et ces variations perturbent les installations. Sous GoboLinux, ces variations seront donc spécifiées dans un "recipe" (traduction : "recette"), une sorte de micro-script utilisé par le programme Compile pour que le programme s'installe correctement.

Le "recipe" est une sorte de fichier de configuration de l'installation que le programme Compile utilise à l'installation de chaque programme. En effet, pour chaque installation, Compile a besoin d'un "recipe". Deux possibilités sont offertes...

• Soit Compile télécharge le "recipe" sur le serveur de GoboLinux http://recipes.gobolinux.org/r/, et dans ce cas ce fichier est stocké dans le dossier /Files/Compile/Recipes.
• Soit il est possible de créer soi-même son propre "Recipe" avec des outils fournis comme "MakeRecipe" ou "NewVersion", dans ce cas le fichier sera stocké dans /Files/Compile/LocalRecipes et Compile utilisera ce "recipe" en priorité.

Le "recipe" est obligatoire pour l'installation de chaque programme. Le petit script "MakeRecipe" automatise la création de "recipe" pour un programme non présent sur le serveur. Il suffit de lui donner un URL et il va télécharger le Tarball, le décompresser et l'inspecter pour comprendre comment il doit être compilé (en utilisant "make", "perl", "python", ou un script de configuration). Si aucun message d'erreur n'oblige à modifier le "recipe", vous pouvez lancer Compile juste après.

Typiquement, le "recipe" standard d'un programme qui ne pose aucun problème d'installation ressemble à ceci (sachant que la seconde ligne est facultative) :

url=$httpSourceforge/gphoto/libgphoto2-2.1.3.tar.bz2
is_compileprogram=yes

Il contient simplement l'URL où le programme a été téléchargé, et la méthode d'exécution. La méthode compileprogram est normalement la plus courante, c'est la méthode qui est appliquée par défaut même si la ligne is_compileprogram=yes n'est pas présente.

Le "recipe" sert à spécifier un modèle d'exécution pour le programme Compile. Il existe plusieurs modèles :

• compileprogram, qui regroupe les programmes dont la configuration est incluse dedans.
• makefile, qui regroupe les programmes à assembler avec un "make".
• xmkmf, qui regroupe les applications basées sur "X imake tools".
• meta, qui supporte le meta-packaging (mélanger plusieurs paquets en un).

Le "recipe" permet d'indiquer à Compile des variations mineures qui existent dans l'installation des programmes.

• Par exemple, pour "PSUtils", la commande "makefile" s'appelle "Makefile.unix", il est possible de le spécifier avec makefile=Makefile.unix.
• Par exemple, lorsque vous décompressez l'archive audacity-src-1.0.0-2.tar.gz, les fichiers ne sont pas dans le dossier audacity-src-1.0.0-2 mais dans audacity-src-1.0.0, donc il faut préciser dir=audacity-src-1.0.0 dans le "recipe". Malheureusement, certains paquets réclament des scripts pré et post installation, car ils s'installent selon des spécificités très éloignées des standards Linux. Les fonctions de script "shell" sont supportées pour ces cas-là.

L'essentiel de la maintenance de GoboLinux consiste à maintenir à jour les différents "recipe" de chaque programme un peu particulier afin d'éviter à l'utilisateur d'avoir des difficultés d'installation. Début 2016, il existe des "recipes" pour environ 3500 paquets.

Cela peut apparaître comme étant un travail énorme, mais maintenir les "recipes" des paquets est bien moins compliqué que de maintenir la compatibilité des paquets eux-mêmes, comme le font les distributions Linux telles que Debian. Et au pire, il est possible de créer soi-même un "recipe" en étudiant la façon dont les paquets sont installés.

En règle générale, chaque paquet a besoin d'un "recipe". Les exceptions sont les paquets programmés dans un langage de script pouvant être géré par un paquet déjà installé (CPAN du Perl, Cabal du Haskell, LuaRocks du Lua, RubyGems du Ruby, et PIP du Python), ces paquets n'ont pas besoin de "recipe". Il suffit d'indiquer la dépendance sur le modèle "PackageManager: PackageName" (par exemple: CPAN:XML::Parser), et Compile laissera son gestionnaire de paquet traiter les détails de l'installation de ce programme.

Le programme Compile va permettre d'installer plusieurs versions d'un même programme, et décider celle(s) que vous souhaitez tenir à jour grâce à des fichiers de configuration présent dans le dossier d'installation de chaque programme.

• Vous pouvez installer plusieurs versions d'un même programme, par exemple...

/Programs/Firefox/37.0.1/
/Programs/Firefox/40.0.3/
/Programs/Firefox/41.0.2/
/Programs/Firefox/42.0/

• Et vous pouvez installer plusieurs fois la même version d'un programme, par exemple...

/Programs/Firefox/42.0/1/
/Programs/Firefox/42.0/2/
/Programs/Firefox/42.0/3/
/Programs/Firefox/42.0/4/

Pour faire cela, il faut lancer Compile avec le paramètre -e <version> qui permet de modifier le nom du dossier de la version du programme contenu dans /Programs/[Nom du programme]/.