Un paquet Nbuild est une archive tar renfermant toutes les informations et ressources nécessaires pour “construire un projet” et l’emballer dans un paquet Nba.

Un “projet” consiste généralement en un logiciel, et le “construire” revient à compiler ses fichiers sources pour obtenir une application exécutable. Un paquet Nba est alors généré avec le résultat de cette compilation. Mais un project peut aussi être autre chose qu’un logiciel. Il peut s’agir d’une documentation, d’un ensemble de polices de caractères ou d’images, d’un thème de curseur souris ... Pour ce type de projet, il n’y a pas de fichiers sources à compiler, mais simplement des fichiers de nature diverse à “préparer” pour qu’ils soient installés de la manière la plus appropriée grâce à un paquet Nba. Aussi, on parle plus généralement des “ressources” d’un projet pour désigner l’ensemble des fichiers qui le constituent, qu’il s’agisse de fichiers sources ou de fichiers d’un tout autre type.

Toutes les informations contenues dans un paquet Nbuild sont exploitées par la commande Build de Ncooker. C’est elle qui permet de générer un paquet Nba à partir d’un paquet Nbuild.

Hormis les nbuilds classiques, générant des paquets Nba, des nbuilds particuliers peuvent être créés : ils ne construisent pas de projets, mais exécutent simplement des commandes (voir le fichier build plus loin). Un tel nbuild pourrait être utilisé pour configurer les droits d’accès aux différents répertoires par exemple. Cela permettrait aussi d’avoir des ‘saveurs’ de Nasgaïa. Suivant le niveau de sécurité que l’on veut, un paquet spécifique peut servir à définir le comportement général.

Le fichier infos est un document au format xml contenant des informations sur le projet et sur le paquet Nbuild lui-même. Ncooker utilise un schéma XML pour vérifier facilement sa syntaxe et sa structure à l’aide de l’utilitaire XMLStarlet. Toute anomalie est alors détectée, qu’il s’agisse d’un texte mal placé ou de l’utilisation d’une balise non reconnue.

Le fichier est composé de deux parties :

• les informations sur le projet (<project>), parmi lesquelles on retrouve son nom (<name>), sa version (<version>), sa licence (<licence>), son auteur (<author>), son copyright (<copyright>) et l’adresse de son site web (<homepage>). Viennent ensuite une description de ses fonctionnalités dans différentes langues (<purpose>), et la définition de son domaine d’application (<domain>), avant de terminer par la liste des ressources qui le composent (<resources>) et les options de construction à utiliser par défaut (<build>).

• les informations sur le paquet Nbuild (<package>) qui comprennent le numéro de release actuel du paquet (<release>), et les modifications qui ont été apportées aux releases précédentes (<changelog>).

Son rôle

La construction du projet est réalisée en plusieurs étapes par la commande build de Ncooker. Pour l’ensemble de ces étapes, elle sélectionne un jeu d’instructions internes prédéfini et adapté au projet. Le choix du jeu d’instructions à utiliser se fait en fonction de certains fichiers présents ou non dans les ressources du projet, et les instructions associées à chaque étape ne sont exécutées que si elles sont appropriées.

Il peut arriver cependant que les instructions utilisées par défaut ne soient pas adaptées à certains projet. C’est ici que le fichier “build” trouve son utilisé : il est possible de redéfinir les instructions à exécuter pour certaines étapes en les plaçant dans ce fichier.

Son contenu

Au sein du fichier build, les instructions sont regroupées dans des fonctions dont le nom commençe par “do_*”. Chacune d’elles correspond à une étape donnée du processus de fabrication conduisant à l’obtention d’un paquet NBA.

Voici la liste des fonctions (et donc des étapes) dans l’ordre où elles sont appelées par Ncooker :

• do_unpack() : cette fonction permet de réaliser soi-même la décompression des ressources du projet au lieu de laisser Ncooker le faire.

• do_patches() : cette fonction permet d’appliquer les correctifs (patches) se trouvant dans le paquet Nbuild aux ressources du projet.

• do_preconfig() : cette fonction permet de mettre en place ou de modifier certaines choses avant que l’environnement de construction/compilation soit généré à l’étape suivante. Il peut s’agir par exemple de modifier certains fichiers du projet ou de positionner des variables d’environnement.

• do_config() : cette fonction génère l’environnement de construction/compilation. Si le projet utilise les outils de compilation GNU, c’est à cette étape que le script ./configure doit être lancé.

• do_premake() : cette fonction permet de mettre en place ou de modifier certaines choses dans l’environnement de construction/compilation généré avant que la construction soit effectivement effectuée à l’étape suivante. Il peut s’agir par exemple de modifier certains fichiers ou de positionner des variables d’environnement.

• do_make() : cette fonction lance la construction du projet. Si le projet utilise les outils de compilation GNU, c’est à cette étape que la commande make doit être lancée.

• do_check() : cette fonction permet de vérifier que le résultat de la construction du projet est correct. Si le projet utilise les outils de compilation GNU et qu’il offre cette fonctionnalité, un simple make check ou make test permet de lancer une série de tests pour valider que l’application s’est compilée correctement. C’est particulièrement important pour les librairies de base du système.

• do_preinstall() : cette fonction permet de préparer l’environnement avant que le projet soit installé à l’étape suivante dans un “fakeroot”, un dossier utilisé comme s’il s’agissait de la racine de l’arborescence du système.

• do_install() : cette fonction procède à l’installation du projet dans le fakeroot. Si le projet utilise les outils de compilation GNU, cette opération est réalisée en faisant appel à la commande make DESTDIR=$PRJ_FAKEROOT_DIR install où la variable $PRJ_FAKEROOT_DIR, positionnée par Ncooker, contient le chemin d’accès au fakeroot.

• do_postinstall() : cette fonction permet de « finaliser » l’installation. Tout dépend ici des besoins du projet, il peut s’agir par exemple de créer un fichier de configuration par défaut. Elle est également utilisée pour copier les ressources incorporées au NBUILD dans le fakeroot, comme un fichier *.desktop par exemple. Enfin, c’est une étape appropriée pour nettoyer les fichiers objets (binaires et librairies) de leurs symboles (comme les symboles de débuggage par exemple), ce qui permet de réduire leur taille.

• do_packages() : cette fonction génère le paquet NBA avec le contenu du projet installé dans le fakeroot. Elle doit utiliser pour cela la fonction Ncooker create_nba. Cette fonction génère automatiquement des informations supplémentaires comme la liste des fichiers constituant le projet installé, la liste des dépendances nécessaires à son bon fonctionnement, etc. Tout ceci est assemblé pour former un paquet NBA. (Ajouter la possibilité de générer plusieurs NBAs à partir d’un seul NBUILD est à l’étude. L’idée est de séparer en plusieurs paquets NBA le résultat de la construction du projet pour que l’utilisateur final n’installe que les “parties” du projet dont il a besoin.)

• do_help() : cette fonction particulière n’est pas associée à une étape du processus de construction du projet. Elle est appelée par Ncooker lorsque l’utilisateur veut obtenir des informations sur la manière dont le projet est construit, afin de la modifier grâce à certaines options de la commande Build de Ncooker. Elle peut, par exemple, afficher les options utilisables pour la génération de l’environnement de construction/compilation (les options du script ./configure dans le cas des outils de compilation GNU), celles qui sont utilisables pour la construction du projet (étape do_make), ou encore afficher le contenu des fichiers README ou INSTALL s’ils sont fournis dans les ressources du projet.

Pour définir de nouvelles instructions pour une étape de construction donnée, il faut les placer dans le corps de la fonction “do_*” correspondante du fichier build.

Les ressources propres à un projet en sont pas intégrées directement dans un paquet Nbuild. Seules les informations permettant de les récupérer sur Internet sont fournies. Cependant, le paquet Nbuild peut intégrés directement des ressources supplémentaires comme des correctifs (patches) ou des fichiers complémentaires tels que des fichiers de configuration, par exemple.

Les patches doivent être placés dans un dossier patches/ à l’intérieur du paquet Nbuild. Ils seront automatiquement appliqués aux ressources du projet par Ncooker.

Les autres ressources doivent être placés dans un dossier res/. Elles ne sont pas traitées automatiquement, et il est nécessaire de redéfinir la fonction do_postinstall() dans le fichier build pour indiquer comment elles doivent être utilisées.

Les Nbuilds officiels, livrés par défaut sur le CD d’installation de la distribution Nasgaïa et ceux ajoutés et vérifiés par l’équipe de dev, devraient être signés. Les Nbuilds de contribution ou les Nbuilds officiels modifiés, ne devraient pas être signés, ou du moins ne pas l’être par rapport à une signature provenant de Nasgaïa.