Source Mage GNU/Linux

Programmes
Projet Speedtouch
Projet Snoopy
Projet eciadsl
La recette du pain
Source Mage
BeOS
Mon CV
Mon blog
Notes
On nous prend pour des cons!
Don

en fr

Spécification de l'installation de logiciel à partir de binaires précompilés

Benoît Papillault, 23/11/2004

Objectifs

L'installation d'un logiciel au sein de la distribution Source Mage GNU/Linux est réalisée en utilisant la commande cast qui va télécharger et compiler le logiciel à partir des sources. Dans le cadre de la réalisation d'un CD-ROM d'installation, cette option n'est pas réaliste. Nous allons donc analyser ce que fait cast pour tenter de le reproduire en utilisant les fichiers présents dans /var/cache/sorcery.

Les différents types de spell

Il existe actuellement deux types de spells : BUILD_API=1 et BUILD_API=2. Il s'agit d'une variable shell indiquant la structure du spell. Celle ci peut-être définit à 3 endroits (nous prenons ici l'exemple du spell glibc du grimoire stable):

Au niveau du grimoire entier: /var/lib/sorcery/codex/stable/API_VERSION
Au niveau de la section: /var/lib/sorcery/codex/stable/libs/API_VERSION
Au niveau du spell: /var/lib/sorcery/codex/stable/libs/glibc/DETAILS

L'absence de cette variable équivaut à BUILD_API=1.

Ce que fait `cast` (BUILD_API=1)

Nous ne détaillerons ici que ce qui nous intéresse pour la suite. L'intégralité de la compilation est surveillée par l'outil installwatch, ensuite le fichier POST_INSTALL s'il existe est exécuté.

Une fois tout cela fait, le cache binaire dans /var/cache/sorcery ainsi que le fichier des sommes MD5 est construit. Cela signifie concrétement que le script POST_INSTALL ne doit pas modifier ces fichiers. Sinon, la vérification des sommes MD5 faites par cleanse échouera.

Ce que fait `cast` (BUILD_API=2)

Le processus est en tout point identique, sauf que le fichier POST_INSTALL est remplacé par le fichier FINAL.

Installation à partir de binaires précompilés

L'installation est faite en 4 étapes:

installation des dépendances en utilisant le même processus récursivement. Ces dépendances sont listées dans le fichier DEPENDS du grimoire avec les fonctions depends et optional_depends.
Attention: sorcery ne permet pas le suivi des dépendances optionnelles. Par exemple, openssl est une dépendance optionnelle de irssi. Si vous compilez irssi en sélectionnant openssl, le binaire résultant ne fonctionnera que si openssl est installé. Hors, si vous installez ensuite irssi à partir du cache binaire, sorcery n'installera pas openssl. Pourtant, ces dépendances (optionnelles ou non) sont enregistrées dans /var/state/sorcery/depends.
extraction des fichiers binaires à partir de l'archive présente dans /var/cache/sorcery. Cette archive pourra également être récupérée sur divers support locaux (système existant, partition, CD-ROM, montage nfs) ou réseaux (http, ftp, ...).
Dans le cas d'un support réseau, il faut trouver un moyen de lister les archives disponibles. Le plus simple étant de créer un fichier ls contenant le résultat de la commande ls.
Mise à jour des fichiers de sorcery:
- /var/state/sorcery/packages
- /var/state/sorcery/depends
- /var/cache/sorcery/$SPELL-$VERSION-$HOST.tar.bz2 (optionel)
lancement d'un script post-installation: POST_INSTALL pour BUILD_API=1 et FINAL pour BUILD_API=2. Ce script, ainsi que la détermination de BUILD_API dépend du grimoire. Il y a donc un risque de problèmes potentiels si le grimoire ne correspond pas à celui utilisé lors de la compilation.

Format et emplacement des fichiers

Les différents fichiers nécessaires à l'installation de binaires précompilés se présentent sous plusieurs formes:

dans un système déjà installé: (ce que fait approximativement la fonctionnalité resurrect de cast)
- version installée : /var/state/sorcery/packages
- dépendances : /var/state/sorcery/depends
- binaire précompilés (optionel): /var/cache/sorcery/${SPELL}-${VERSION}-${HOST}.tar.bz2 liste des fichiers: /var/log/sorcery/install/${SPELL}-${VERSION}
- script de post-installation:
  - POST_INSTALL si BUILD_API=1
  - FINAL si BUILD_API=2
dans un système distant (ftp/http/rsync/cvs/scp) ou local (partition, nfs). Ce système sera en fait un unique répertoire contenant tout les binaires précompilés ainsi qu'un fichier ls. Il sera accessible symboliquement par une URL ${BASE} que nous allons utiliser pour la description.
- liste des binaires précompilés présents dans le fichier ${BASE}/ls
- ${BASE}/${SPELL}_${VERSION}_${HOST}.tar.bz2 contenant:
  - la liste des fichiers à installés, par exemple:
```
usr/bin/which
usr/share/info/which.info
usr/share/man/man1/which.1
var/log/sorcery/compile/which-2.16.bz2
var/log/sorcery/md5sum/which-2.16
var/log/sorcery/install/which-2.16
```
  - install/depends
    sera créé à partir des lignes correspondantes de /var/state/sorcery/depends. L'intégralité des lignes devra être copiée, pour les restaurer dans le système à installer. Par exemple:
```
irssi:glib2:on:required::
irssi:ncurses:on:required::
irssi:openssl:on:optional::--disable-ssl
irssi:perl:off:optional:--with-perl=module:--with-perl=no
```
  - install/postinst
    est une copie de POST_INSTALL ou FINAL suivant le cas.
dans un système copié sur une ISO. Il s'agit d'un système hybride dans lequel on cherche à gagner de la place. On trouvera donc des logiciels dans les deux version présentés ci-dessus: soit déjà installé, soit sous forme de tar.bz2 dans le répertoire /install.

Outils

Afin d'utiliser concrétement le système présenté ici, nous avons besoin de deux outils : un outil permettant de générer les fichiers tar.bz2 avec un répertoire install (spell-binary-make) et un outil permettant de les installer (spell-binary-install).

spell-binary-make

Usage: [BASE=/install] [INSTALL_ROOT=/mnt/root] spell-binary-make spell
Prérequis: Le spell, ainsi que ses dépendances, doivent être installés.
Sortie: un fichier ${SPELL}_${VERSION}_${HOST}.tar.bz2 dans le répertoire ${BASE} pour le spell et toutes ses dépendances.
Note: le nom du spell peut être modifié dans certains cas. En effet, le caractére _ est utilisé comme délimiteur, donc les caractéres _ du nom du spell sont remplacés par -.
BASE précise le répertoire destination contenant le fichier ${SPELL}_${VERSION}_${HOST}.tar.bz2 et INSTALL_ROOT précise le répertoire racine du système source. Valeurs par défault: BASE=. et INSTALL_ROOT=/

spell-binary-install

Usage: [BASE=/install] [INSTALL_ROOT=/mnt/root] spell-binary-install spell
BASE précise le répertoire source contenant le fichier ${SPELL}_${VERSION}_${HOST}.tar.bz2 (il peut s'agir d'une URL) et INSTALL_ROOT précise le répertoire racine du système destination. Valeurs par défault: BASE=. et INSTALL_ROOT=/
Si aucun fichier ${SPELL}_${VERSION}_${HOST}.tar.bz2 n'existe, une installation est tentée est utilisant le système déjà installé. Ce mode est utilisé pour l'ISO.

Implémentation

Les deux outils sont implémentés sous forme de scripts shell bash et peuvent être téléchargés:

Cette implémentation comporte des restrictions:

Il est maintenant possible de faire un paquet avec un spell n'ayant pas de cache
L'utilisation de spell-binary-make avec autre chose que INSTALL_ROOT=/ peut produire des comportements erronés
L'utilisation de spell-binary-installavec une URL utilisant http/ftp est possible dans cette implémentation
L'utilisation de spell-binary-install avec autre chose que INSTALL_ROOT=/ peut entraîner des bugs dans le script de post-installation
Les fichiers aliens ne sont pas installés

Utilisation possible

Réduction de la taille de l'ISO

Ce système permet d'éviter d'avoir des binaires précompilés si l'ISO contient déjà les spells installés.

Exemple :

BASE=/install INSTALL_ROOT=/mnt/root spell-binary-install irssi

Installation à partir d'un autre support ou du réseau

Ce système permet de réaliser ce qui est communément appellé netinstall et permet ainsi la réalisation d'une ISO ne contenant aucun binaires précompilés. Ceci peut également permettent de mettre à jour les binaires précompilés sans devoir mettre à jour l'ISO, réduisant ainsi le coût de la mise à jour et de la maintenance.