Projet de distribution GNU/Linux
Projet de distribution GNU/Linux
Auteurs: Martial Daumas <martial@nasgaia.org>
Date: 2003-04-07
Dernière Modif: 2003-05-10
Fonctionnement et utilisation de Ncooker2
Ncooker2 est un ensemble de commandes et de scripts destiné à permettre la compilation de logiciels depuis les sources, en faire des paquets nba installables. La commande principale de Ncooker2 est Nmake2, qui selon les options et arguments passés à la ligne de commande, va déclencher une série d'opérations, parmi lesquelles (description complète plus loin dans ce document):
Ncooker2 requiert, pour chaque logiciel, un Nbuild, qui est une archive tar qui contient le script de compilation, le descriptif, les patches éventuels, d'autres ressources. L'anatomie d'un Nbuild est décrite en détail plus loin.
Le choix de stocker les procédures et informations requises à la création d'un nba dans une archive tar a été motivé par la grande souplesse que cela donne, par rapport à la version précédente de Ncooker, où les informations pour chaque paquet étaient dispersées dans une multitude de fichiers (Makefiles, fichiers XML, scripts...) - et cela permet aussi de transporter par exemple un patch requis ou des icônes faits maison dans un Nbuild.
Cela permet de beaucoup simplifier et uniformiser la partie du Nbuild qui s'occupe de la compilation. Le Nbuild fournit toutes les informations requises pour un paquet, sauf les sources - mais il contient les informations pour que Ncooker2 puisse les récupérer/préparer/stocker à la demande.
Dans cette nouvelle version du format nba, le fichier nba est lui aussi une archive tar, et aussi un Nbuild. Un paquet nba est en fait le Nbuild d'origine (informations sur la procédure) PLUS une archive data.tar.bz2 (les fichiers à installer à la racine) PLUS de nombreuses informations diverses (dépendances, bibliothèques fournies, environnement de compilation...).
De fait, tout nba peut servir de Nbuild (en changeant l'extension .nba en .tar), et par défaut, l'installation d'un nba extrait le Nbuild correspondant, qu'un mode de Ncooker2 permet d'utiliser pour recompiler le paquet (par exemple, en utilisant vos propres optimisations ou changements).
Le choix du format tar pour les nba a été motivé par le besoin de pouvoir extraire à la volée et de manière rapide la partie "informations" d'un nba, par contre, tout ce qui constitue des données brutes est compressé au mieux avec bzip2 (donc gain de temps pour l'accès aux informations, gain de taille pour le nba)
L'idée qui est derrière tout cela, est que tout ce que vous pouvez installer en nba, vous devez être en mesure (si l'envie vous en prend) de le recompiler par vous-même - cela par souci de transparence, mais aussi d'informations et de compréhension. Savoir exactement ce que l'on installe est toujours bon, et encore plus de comprendre comment le refaire.
Description complète dans la page de man Nmake2(8), extrait:
SYNOPSIS
Nmake2 [pkg_list]
Nmake2 [-g] [-s] [-p option || -p 'option1 option2 ...'] [pkg_list]
Nmake2 [-g] [-r] [-p option || -p 'option1 option2 ...'] [pkg_list]
pkg_list est commun à tous les modes d'appel, et doit être une liste de noms de paquets séparés par des espaces. Les noms peuvent être incomplets (vers la droite), du moment qu'il n'existe pas d'ambiguïté, dans le cas contraire, Nmake2 vous présente la liste des choix possibles.
Dans nos exemples, pkg_list vaudra paquet1 paquet2 paquet3
La première méthode d'appel entraîne la recherche et la validation structurelle des nba correspondant aux paquets spécifiés dans [pkg_list].
Les Nbuilds sont cherchés récursivement parmi $NBUILDS_DIR, si paquet1.tar existe, il sera validé et ensuite le même processus intervient alors pour paquet2.
La validation n'a pas pour but de dire si le Nbuild est réellement utilisable, mais de vérifier qu'il contient les informations requises, aux bons endroits, et d'en afficher certaines.
Après la recherche du Nbuild (paquet1.tar), celui-ci est analysé pour déterminer s'il contient trois fichiers obligatoires: build desc infos. L'absence de l'un de ces trois fichiers est une erreur.
Après ce 1er test, le fichier infos est lu pour vérifier que cela n'entraîne pas d'erreur. La description courte du paquet extraite de desc est affichée, dans les langues que le Nbuild propose.
La dernière étape consiste à afficher toutes les variables définies par le fichier infos
Le mode --static (-s) n'est disponible que pour certains Nbuilds dont le script build contient la fonction spéciale do_static.
Ceci est utilisé pour créer un chroot (de manière similaire à ce que fait LFS) minimal. Ceci ne sert que pour créer une Nasgaïa depuis le tout début, et comme nous fournissons des nba tout prêts pour le système de base, vous n'en avez pas vraiment besoin, vous pouvez passer directement à la phase normale (avec -b ou -r) - mais cela est fourni pour référence et expérimentations.
Attention, selon les versions de système de départ et logiciels employés, le passage d'un chroot statique à un chroot normal peut être très complexe (par exemple, besoin de compiler glibc dynamiquement deux fois, en attendant que nous utilisions la méthode de pure-LFS), ce n'est donc pas expliqué ici.
| Note 1: -s n'a de sens qu'accompagné soit de -b soit de -r (ex: Nmake2 -rs foo signifie "recompile la version statique du paquet foo" |
| Note2: Avec cette option, aucun nba n'est créé, mais les logiciels sont installés dans $N_STATROOT, qui doit pointer par exemple sur le répertoire /static du futur chroot (lire le LFS book). |
Le mode --build cherche tout d'abord un Nbuild correspondant dans $NBUILDS_DIR, vérifie qu'il est valide, en extrait les informations requises, décompresse les sources indiquées et stockées dans $SOURCES_DIR, compile le paquet dans $N_COMPILE_DIR, l'installe temporairement dans $N_INST_ROOT_DIR, en fait un paquet nba, le stocke dans $NBA_OK_DIR - et peut l'installer si la demande en est faite.
La grosse différence avec l'ancien Ncooker2 (jusqu'à Nasgaïa-0.9) est que le paquet est créé sans rien installer sur le système, et que le contrôle des erreurs est plus rigoureux (tout s'arrête à la moindre erreur).
Le mode --rebuild (-r) est similaire au mode -b à la différence que le Nbuild est cherché dans $BINST_NBUILDS_DIR, qui est l'endroit ou npkg extrait à la volée un Nbuild depuis un nba lors de son installation, ceci permet donc de recompiler tout nba qui est déjà installé, ce qui peut être intéressant si vous voulez qu'il prenne avantage de choses installées entre-temps, compiler avec un autre niveau d'optimisation, ou utiliser d'autres options si vous avez édité le Nbuild entre-temps.
Le mode --getsrc (-g) peut-être utilisé seul ou en complément avec -b ou -r, et déclenche la récupération (avec wget) des sources requises si elles sont manquantes ou incomplètes, puis leur préparation éventuelle, qui consiste à tout transformer au format tar.bz2 (le seul format que comprend Ncooker2), et si besoin de réempaqueter le contenu d'une archive dans un répertoire avant recompression (cela permet de gérer par exemple certains ZIP ou TGZ qui ne contiennent que des fichiers, ou un/des répertoire(s) aux noms qui posent problème - au final, le contenu DOIT être situé dans son propre répertoire dans lequel on pourra opérer tranquillement).
Chaque Nbuild DOIT fournir au minimum, une URL pour l'archive principale, il s'agit de la variable PRI_DL_URL du fichier infos. Le paquet peut avoir besoin de sources supplémentaires, qui sont spécifiées dans la variable tableau ${NEEDED_RES[N]}, où N est un entier (commence à 0).
La conversion vers tar.bz2 est automatique si le format est reconnu (actuellement: zip, tar.gz, rar - d'autres viendront sans doute).
L'empaquetage dans un répertoire supplémentaire à lieu si la variable REPACK_IN n'est pas vide, et est converti en tar.bz2 après.
Les mêmes opérations sont effectuées, dans l'ordre avec chacune des sources spécifiées dans le tableau $NEEDED_RES, dont voici la syntaxe:
NEEDED_RES[N]="URL,MODE,REP"
URL est une adresse http ou ftp valide, MODE est soit auto ou noauto. auto indique d'automatiquement décompresser (lorsque Nmake2 sera appelé avec -r ou -b) cette archive dans $N_COMPILE_DIR/$NODE/{$CREATE_DIR||$REPACK_IN}. Parfois, le script build peut gérer lui-même la décompression de ces sources, dans ce cas, il faut employer noauto. REP (optionnel) indique le nom du répertoire de réempaquetage (similaire au REPACK_IN avec l'archive principale).
Le passage de paramètres se fait avec --params (-p), suivi d'un mot-clé, ou d'une liste de mots-clés séparés par des espaces. S'il y a plusieurs mots-clés, ceux-ci doivent être entourés d'apostrophes simples ou doubles ( -p 'param1 param', -p "param1 param2" et -p param sont donc corrects), sans quoi ils seraient interprétés comme faisant partie de [pkg_list].
Voici les mots-clés utilisables:
wipe Force la destruction préalable du répertoire de compilation s'il existe déjà.
install Indique d'installer (avec installnpkg2) chaque nba produit avec succès, sur le système, avec les options par défaut (écrasement).
makeclean fait exécuter la commande make clean avant de compiler.
makedistclean fait exécuter la commande make distclean avant de compiler.
skip_validity Indique de ne pas tester la validité des sources, c'est-à-dire ne ne pas vérifier que les sources contiennent bien le répertoire $CREATE_DIR ou $REPACK_IN (et même chose pour les achives supplémentaires NEEDED_RES) qu'elles sont supposées contenir. Cette opération peut prendre beaucoup de temps sur des archives de bonne taille (ex: Kernel, Mozilla, X), ceci permet donc de sauter cette étape si vous faites de multiples essais successifs avec un même paquet.
skip_integrity Indique de ne pas tester l'intégrité du tar.bz2 avec bzip -t, qui comme dans le cas précédent prend du temps - si cela avait fonctionné la première fois, vous gagnez ainsi du temps avec ce paramètre.
skip_unpack Indique de ne décompresser aucune source, principale ou additionnelle. Pour ce qui concerne les sources gérées directement par le fichier build, celui-ci ne doit décompresser que si la variable $options_skipunpack n'est pas définie (via Nmake2). Ceci permet de réutiliser un répertoire de compilation déjà existant.
Le script build fournit diverses fonctions, chacune gère une partie spécifique du processus, par exemple l'application de patches ou magie-sed est lancée par do_preconfig(), la commande make par do_make() etc...
Les mots-clés suivants permettent de ne pas exécuter les parties choisies (pour trouver le nom de la fonction, remplacer skip_ par do_):
skip_preconfig skip_config skip_premake skip_make skip_preinstall skip_install skip_postinstall skip_package
Vous pouvez en spécifier autant que vous voulez, dans n'importe quel ordre (Ncooker2 suivra l'ordre normal dans tous les cas, et sautera les parties indiquées).
