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

Revue de la fonctionnalit� INSTALL_ROOT de sorcery

Beno�t PAPILLAULT, 23/11/2004

Objectifs

Nous avons:

la documentation existante n'est pas clair (comment sont d�finis les variables? comment elle doivent �tre utilis�es par les auteurs de spell? pourquoi install_root est utilis� dans la documentation et INSTALL_ROOT dans le code source de sorcery?)
l'impl�mentation existante ne fonctionne pas (le spell glibc ne peut pas �tre compil� pour un syst�me chroot ou la cross compilation d'un syst�me x86_64 ne fonctionne pas).

Nous voulons:

une documentation claire qui puisse servir de point de d�part pour une impl�mentation claire.
g�rer plusieurs configurations:
- un syst�me normal
- un syst�me chroot
- la cross compilation d'un syst�me
- l'installation d'un spell en conflit dans un endroit diff�rent

D�finitions

Comme ce que nous allons d�finir va principalement �tre utilis� avec le syst�me autoconf, il est mieux d'utiliser des noms de variables similaires. Nous choisissons des noms diff�rents de ceux d�j� utilis� pour �viter des confusions et pour v�rifier rapidement si le code l'impl�mente proprement.

Avec le syst�me autoconf, BUILD est utilis� pour d�signer le syst�me de compilation, ie la machine o� le logiciel est compil�. HOST est utilis� pour d�signer le syst�me h�te, ie la machine o� le logiciel sera ex�cut�.

BUILD_ROOT est le r�pertoire racine du syst�me o� les binaires sont install�s. C'est un r�pertoire du syst�me de compilation. Sa valeur par d�faut est /
HOST_ROOT est le r�pertoire racine du syst�m� o� les binaires sont ex�cut�s. C'est un r�pertoire du syst�me h�te. Sa valeur par d�faut est /

Ces deux variables sont d�finies par sorcery and doivent �tre correctement utilis�s par les scripts des spells.

Utilisation de BUILD_ROOT et HOST_ROOT dans un spell

spell conforme � BUILD_API=1

Les spells conformes � BUILD_API=1 sont des vieux spells et devraient �tre converties vers des spells conformes � BUILD_API=2.

si aucun fichier BUILD n'existe, la fonction default_build() est utilis�e � la place. Donc, les auteurs du fichier BUILD doivent l'utiliser comme mod�le. Voici son code:

./configure --prefix="${HOST_ROOT}/usr" \
        --sysconfdir="${HOST_ROOT}/etc" \
     --localstatedir="${HOST_ROOT}/var" \
            --mandir="${HOST_ROOT}/usr/share/man" \
           --infodir="${HOST_ROOT}/usr/share/info" \
  $OPTS &&
make &&
prepare_install &&
make install prefix="${BUILD_ROOT}/usr"

spell conforme � BUILD_API=2

si aucun fichier BUILD n'existe, la fonction default_build() est utilis�e � la place. Donc, les auteurs du fichier BUILD doivent l'utiliser comme mod�le. Voici son code:

./configure --prefix="${HOST_ROOT}/usr" \
        --sysconfdir="${HOST_ROOT}/etc" \
     --localstatedir="${HOST_ROOT}/var" \
            --mandir="${HOST_ROOT}/usr/share/man" \
           --infodir="${HOST_ROOT}/usr/share/info" \
  $OPTS &&
make

si aucun fichier INSTALL n'existe, la fonction default_instal() est utilis�e � la place. Donc, les auteurs du fichier INSTALL doivent l'utiliser comme mod�le. Voici son code source:
```
make install prefix="${BUILD_ROOT}/usr"
```

Diff�rentes fa�cons d'utiliser la fonctionnalit� BUILD_ROOT

Syst�me normal

BUILD_ROOT=/
HOST_ROOT=/

Syst�me chroot ou syst�me cross compil�

Dans ce cas, le syst�me doit fonctionner apr�s avoir fait un chroot /mychroot (dans le cas du chroot) ou apr�s avoir copi� le r�pertoire /mychroot sur une autre machine and la lancer avec celui en r�pertoire racine.

BUILD_ROOT=/mychroot
HOST_ROOT=/

Syst�me normal mais en installant dans /opt/mozilla-special

Ceci peut �tre utilis� pour installer des spells qui sont en conflits, comme vim et elvis.

BUILD_ROOT=/opt/mozilla-special
HOST_ROOT=/opt/mozilla-special

Syst�me normal, installation dans un endroit s�r d'abord

BUILD_ROOT=/opt/safe
HOST_ROOT=/

Encore des am�liorations

Comme sugg�r� dans la documentation existante, on pourrait avoir besoin de d'autres variables pour sp�cifier l'endroit o� se trouve sorcery ou les grimoires.

SORCERY_ROOT: racine des fichiers d'�tat de sorcery ("${SORCERY_ROOT}/etc/sorcery", "${SORCERY_ROOT}/var/cache/sorcery", "${SORCERY_ROOT}/var/state/sorcery", "${SORCERY_ROOT}/var/log/sorcery", )
Ceci peut �tre utilis� lorsque l'on construit un syst�me chroot, pour conserver l'�tat et la configuration du syst�me chroot soit dans le syst�me chroot lui-m�me ou dans n'importe quel autre endroit, diff�rent du syst�me de compilation.
Valeur par d�faut: /
CODEX_ROOT: racine des grimoire. Par exemple, le grimoire stable sera pr�sent dans le r�pertoire "${CODEX_ROOT}/stable".
Valeur par d�faut: /var/lib/sorcery/codex

Etat

Ce qui est d�cris ici n'est pas du tout impl�ment�.

Liens

la distribution Source Mage GNU/Linux: http://www.sourcemage.org/
documentation existante sur INSTALL_ROOT par Andrew STITT: http://wiki.sourcemage.org/index.php?page=install_root+and+others
une autre documentation par Karsten BEHRMANN: http://wiki.sourcemage.org/index.php?page=true+cross_install

Benoît Papillault