Ncooker est le gestionnaire de paquets de Nasgaïa. Il permet d’accomplir plusieurs tâches telles que l’installation, la désinstallation ainsi que la recherche et le téléchargement de paquets. Ncooker permet à chacun de modifier des paquets existants et de créer ses propres paquets.

Spécifications Paquetages

Ncooker est sous GNU GENERAL PUBLIC LICENSE Version 2, June 1991

Ncooker est géré par le fichier de configuration : /etc/Ncooker.conf

Ncooker.conf contient des paramètres indiqués sous forme de variable. Le format utilisé est le suivant :

VARIABLE=”valeur”

Le nom des variables s’écrit en majuscules, et les valeurs doivent être entourées de guillemets, si elles contiennent des espaces. Dans le cas contraire, ils sont optionnels.
Aucun espace ou tabulation ne doit figurer de part et d’autre du signe d’affectation “=”.

Ncooker.conf contient :

• NC_VERBOSITY_DEFAULT=’INFO’

Un choix de niveaux d’information est proposé

• NC_COLOR .........

De nombreuses options couleurs, peuvent être changées sans risque.

• NC_FORCE_DOWNLOAD=’0’

Permet deorcer le téléchargement des paquets ET des archives sources (0/1)

• NC_WGET_OPTIONS=’’

Option wget possible : –passive-ftp

(entendre par là l’utilisateur qui décide de créer des paquets)

• NC_PKG_AUTHOR=’name your_email@domain.org’

Si vous voulez construire des paquets

• NC_PACK_EXCLUDE_FILES=’*~ #*# %*% CVS SCCS vssver.scc’

Options à exclure lors de la création d’un paquet nbuild

A changer à vos risques et périls !

• NC_USER_CONFIG=’.Ncooker/Ncooker.conf’

Localisation du fichier de configuration utilisateur

• NC_DISTRO_NAME=’nasgaia’

Nom de la distribution

• NC_DISTRO_ABBR=’nga’

Abbréviation du nom de la distribution

• NC_CONFIG_DIR=’/etc/Ncooker’

Chemin des fichiers de configuration Ncooker

• NC_MIRRORS_DIR=’/etc/Ncooker/mirrors’

Chemin des fichiers des mirroirs Ncooker

• NC_COMMANDS_DIR=’/usr/bin’

Chemin des exécutables Ncooker

• NC_MODULES_DIR=’/etc/Ncooker/modules’

Chemin des modules Ncooker

• NC_LIBS_DIR=’@FUNCTIONS_DIR@’

Chemin des bibliothèques Ncooker

• NC_LIBS_ERRORS=”${NC_LIBS_DIR}/error.sh”

Chemin de la bibliothèque de gestion des erreurs

• NC_LIBS_MESSAGES=”${NC_LIBS_DIR}/messages.sh”

Chemin de la bibliothèque de gestion des messages

• NC_LIBS_PARAMS=”${NC_LIBS_DIR}/params.sh”

Chemin de la bibliothèque de gestion des paramètres

• NC_NBUILDS_CACHE_DIR=’/var/cache/Ncooker/nbuilds’

Répertoire cache des nbuilds

• NC_NBAS_CACHE_DIR=’/var/cache/Ncooker/nbas’

Répertoire cache des nbas

• NC_SRC_CACHE_DIR=’/var/cache/Ncooker/src’

Répertoire cache des sources

• NC_TEMP_DIR=’@TEMP_DIR@’

Chemin du répertoire temporaire utilisé par Ncooker

• NC_NBUILD_PATTERN=”?*-?*-${NC_DISTRO_ABBR}?*.nbuild”

Format des noms de paquet nbuild

• NC_NBA_PATTERN=”?*-?*-${NC_DISTRO_ABBR}?*-?*.nba”

Format des noms de paquet nba

• NC_CHECK_LANGS=”en fr”

Liste des langues obligatoires pour la description du paquet

• NC_TRANSLATIONS_DIR=’/usr/share/locale’

Répertoire des traductions

• NC_NODES_LIST=’@SHARE_DIR@/NcookerTroveNodes’

Chemin des nodes Troves

Les politiques possibles seront :

1. garder les fichiers de config existants et installer les nouveaux avec une extension *.ncnew
2. renommer les fichiers de config existants en *.ncsave et installer les nouveaux à la place
3. garder le fichier de config existant uniquement s’il a été modifié par l’utilisateur.

Pour cela, il faut utiliser 3 checksums.

Une liste de mirroirs pour gnome, gnu, kde, kernel and sourceforge est incluse dans etc/Ncooker/mirrors.

Les listes sont organisées en fonction du lieu géographique :

• Amérique du Nord
• Amérique du Sud
• Europe
• Afrique
• Moyen-Orient
• Asie
• Australie

La zone Europe contiendra les mirroirs français en tête de liste.

Autre option à l’étude : Tous les miroirs seront proposés par défaut, et il sera ajouté une commande à Ncooker pour qu’il teste les temps de réponses de chacun afin de les classer automatiquement du plus rapide au moins rapide. Ce classement ne serait pas fait à chaque téléchargement, mais uniquement à la demande de l’utilisateur.

Ces deux propositions peuvent être combinées.

Voici l’organisation des répertoires par défaut.
Bien entendu, l’utilisateur est libre de choisir une toute autre organisation, lors de l’installation ou via Ncooker.conf.

The configuration files directory. The main configuration file is Ncooker.conf.
The “mirrors” subdirectory is for files containing URLs of projects mirrors. They are used as alternative URLs to download projects source archives.

Where tools that can be called are stored. For now, there’s only one tool : ‘Ncooker’. But others may arrive one day ...

Where cached files go. Initialy, this contains three empty directories: nbuilds, nbas and src, which will host respectively downloaded nbuilds, downloaded nbas, and downloaded or copied source archives.

Ici seront téléchargés tous les nbuilds.
Les nbuilds se situeront à la racine de ce répertoire, il n’y aura pas de répertoire par nbuild pour différencier les versions nbuild.
L’utilisateur aura la possibilité d’utiliser un autre répertoire en indiquant le chemin relatif.
Exemples : /var/cache/Ncooker/nbuilds/foobar-1.0-nga1.nbuild
/var/cache/Ncooker/nbuilds/foobar-1.0-nga2.nbuild
/var/cache/Ncooker/nbuilds/foobar-2.0-nga1.nbuild
/var/cache/Ncooker/nbuilds/helloworld-1.0-nga1.nbuild

Ici seront téléchargés tous les nbas.
Les nbas se situeront à la racine de ce répertoire, il n’y aura pas de répertoire par nba pour différencier les versions nba.
L’utilisateur aura la possibilité d’utiliser un autre répertoire en indiquant le chemin relatif.
Exemples : /var/cache/Ncooker/nbas/foobar-1.0-nga1-i686.nba
/var/cache/Ncooker/nbas/foobar-1.0-nga2-i686.nba
/var/cache/Ncooker/nbas/foobar-2.0-nga1-i686.nba
/var/cache/Ncooker/nbas/helloworld-1.0-nga1-i686.nba
/var/cache/Ncooker/nbas/helloworld-1.0-nga1-amd64.nba

Ici viendront les sources téléchargées par Ncooker.
Attention : Il y aura un répertoire par version de logiciel.
La version nbuild ne sera par renseignée étant donné que les sources n’ont pas changées.
Exemples : /var/cache/Ncooker/src/foobar-1.0/foobar-1.0.tar.bz2
/var/cache/Ncooker/src/foobar-1.0/foobar-1.0-ressource1.tar.bz2

/var/cache/Ncooker/src/foobar-1.0/foobar-1.0-ressource2.tar.bz2
/var/cache/Ncooker/src/foobar-2.0/foobar-2.0.tar.gz
/var/cache/Ncooker/src/helloworld-1.0/helloworld-1.0-ressource2.tar.bz2

Tous les fichiers relatifs à la compilation des nbuilds/nbas iront dans /var/lib/Ncooker
Where nba generation files will be put. Initialy, this contains two empty directories: compile and instroot, which willhost respectively build process files and exploded image of nbas.
Les archives sont gardées dans leur format d’origine.

Un réperoire par version logicielle ET par nbuild.
Ceci pour éviter toute interaction entre les patchs éventuels apportés par une nouvelle version de nbuild.

Exemples :

/var/lib/Ncooker/compile/foobar-1.0-nga1/
/var/lib/Ncooker/compile/foobar-1.0-nga2/
/var/lib/Ncooker/compile/foobar-2.0-nga1/
/var/lib/Ncooker/compile/helloworld-1.0-nga1/

Un réperoire par version logicielle ET par nbuild.
Ceci pour éviter toute interaction entre les patchs éventuels apportés par une nouvelle version de nbuild.

Exemples : /var/lib/Ncooker/instroot/foobar-1.0-nga1/
/var/lib/Ncooker/instroot/foobar-1.0-nga2/
/var/lib/Ncooker/instroot/foobar-2.0-nga1/
/var/lib/Ncooker/instroot/helloworld-1.0-nga1/

Tous les fichiers relatifs à l’installation des nbuids/nbas iront dans /var/lib/Npkg.
The root directory of the installed packages database. This contains several directories used to manage installation, update or removal of local packages.
Les nbuilds seront référencés par leur nom de version logiciel ET nbuild.

Where Ncooker’s actions will be logged.

Where translation files are put. Ncooker is internationalized with the gettext scheme, so locale messages files go like other programs in a common place.

Where manual pages are put. Switch the type of man page, they will go in man1, man5, etc..

Where Ncooker’s documentation is put.

Where Ncooker’s architecture independent data files are put.

Where helper files needed by tools go. Initialy, this contains three directories: commands, modules and functions.d, which host respectively Ncooker launchable commands, specific task modules and functions libraries.

Contient les scripts appelés par Ncooker.
Il s’agira de fonctions utilitaires et des modules : /usr/lib/Ncooker/functions/ pour les scripts globaux
/usr/lib/Ncooker/modules/ pour les modules

Les modules sont de plusieurs niveaux.
A une commande (Ncooker <commande> <options> <package> <package> ...), correspond un script du répertoire “commands” directement appelé par Ncooker, il s’agit des build, install, remove et consorts.
Chacune de ces commandes peut appeler une autre commande de commands/ (install.sh, remove.sh, build.sh, ...) ou un module de modules/ (download.sh, uncompress.sh, ...).
Certains modules peuvent être composés de sous-modules. Par exemple, le module download (pour récupérer sur le net des packages ou sources) possède les sous-modules http.sh, https.sh, ftp.sh, ...
Il y aura donc pour ce module un répertoire <nom du module>, qui contiendra les sous-modules, et ainsi de suite.

Exemple :

La commande getpkg sert à récupérer des packages (nbuild ou nba).
Suivant ce qu’elle trouve et les noms de packages passés en ligne de commande, getpkg peut avoir besoin de les télécharger sur internet.
La commande getpkg fera donc appel au module ‘download’.
Il existe plusieurs protocoles pour télécharger (http, ftp, etc..); pour être facilement extensible, on décompose donc ce module en sous-modules (http, ftp, etc..) dans /usr/lib/Ncooker :

modules/download.sh
modules/download.d/protocols/mirror.sh
modules/download.d/protocols/http.sh
moduled/download.d/protocols/ftp.sh

Il n’y a pas de module ou sous-module wget, celui-ci est utilisé directement par les scripts http.sh et ftp.sh.
Dans les cas précédents, le téléchargement peut être forcé ou non, en option par défaut dans Ncooker.conf, variable NC_FORCE_DOWNLOAD.

Et, à son tour, un sous-module peut appeler une commande, un autre module ou un sous-modules de même niveau.

Ncooker fournit plusieurs fonctions, il y en a une pour lancer les commandes, une autre pour lancer les modules.
Soit run_command() et run_module().

Quand une commande ou un module veut lancer une autre commande, il appelle run_command() en lui passant juste le nom de la commande avec les options, et Ncooker l’exécute. Idem pour run_module().

Chaque commande ou module doit avoir un sous-rèpertoire nommé <command>.d ou <module>.d qui contient deux fichiers.
Le premier, params.conf, définit les options utilisables avec la commande ou le module.
Le second, error.sh, contient les codes d’erreurs et les fonctions de traitement des erreurs de cette commande ou de ce module.

Le fichier params.conf n’est pas nécessaire si aucune option n’existe, il doit contenir 2 variables : SHORT_OPTIONS et LONG_OPTIONS.
Ce sont deux listes d’options séparées par des virgules, les options qui prennent une valeur doivent être suivies d’un “:”
par exemple :

SHORT_OPTIONS='h,d:,C,b'

Le fichier params.conf est analysé automatiquement par Ncooker lorsque la fonction run_command() est lancée, exemple : run_command toto -h
va utiliser le fichier commands/toto.d/params.conf pour connaitre les options reconnues par toto, toute option inconnue est supprimée.
Dans le script toto.sh, deux variables globales sont disponibles, OPTIONS et OPERANDS.
La premoère contient les options passées à run_command et leurs éventuelles valeurs.
La seconde contient tout ce qui n’est pas une option.
Par exemple, avec SHORT_OPTIONS=’h,d:,C,b’ et run_command toto -t -d salut -C config nous obtenons :

OPTIONS="-d salut -C"
OPERANDS="config"

Pour résumer, toute l’analyse des options est faite par Ncooker.
Le développeur du module doit simplement regarder ce qui se trouve dans les 2 variables et réagir en conséquence.

Mais si toto fait appel à une autre commande ou module ?

Ncooker supprime toute option inconnue, dont certaines peuvent être utilisées par une commande appelée par toto.
Afin d’éviter cela, il y a une troisième variable utilisable dans params.conf : INCLUDE_OPTIONS
Par exemple, INCLUDE_OPTIONS=”commands/download.d/params.conf”
va inclure les options du module download dans le params.conf de toto.
De ce fait, les options passées à run_command et destinées à download seront reconnues et non supprimées.

Pour éviter les chemins en dur, il est préférable d’indiquer : INCLUDE_OPTIONS=”${NC_MODULES_DIR}/download.d/params.conf” pour les modules,
INCLUDE_OPTIONS=”${NC_COMMANDS_DIR}” pour les commandes.
Ces variables sont définies dans /etc/Ncooker.conf.

Ce système permet de spécifier des options pour les commandes et les modules de premier niveau, mais pas pour les sous-modules.
Etant donné que les sous-modules sont appelés par un module qui lui peut prendre des options, on considère que celles-ci servent aussi pour ses sous-modules, mais c’est le module qui les gère.

La lib functions.d/error.sh définit une fonction throw() , cette fonction peut être appelée par une commande ou un module dès qu’il y a une erreur.
Les erreurs (code + fonction de traitement) sont définies pour chaque module ou commande dans leur fichier error.sh

Un code d’erreur est défini par une variable E_<nom de l’erreur>
La fonction de traitement de l’erreur se nomme catch<nom_erreur>() , exemple :

E_NULL=17
catch_NULL() { ... }

si un module fait : throw NULL, le gestionnaire d’erreur appelle automatiquement catch_NULL() ,
si cette fonction retourne 0, c’est que l’erreur a été corrigée,
si elle retourne 1, c’est que l’erreur n’a pas été corrigée.

Si l’erreur n’a pas été corrigée, la fonction throw() retourne la valeur de E_NULL et le module qui a appelé throw NULL réagit en conséquence.
En général, lorsqu’il y a une erreur non corrigée le module qui appelle throw doit retourner la valeur de l’erreur, exemple :

throw NULL
return $?

$? contient la valeur retournée par throw
return fait quitter le module en cours d’exécution pour rendre la main au module ou la commande qui l’a appelé, ce module ou commande parent(e) reçoit donc le code d’erreur à son tour et il peut réagir à cette erreur s’il le souhaite ou bien quitter et retourner à son tour le code d’erreur à son parent. Exemple :

run_command toto || return $?

si l’exécution de la commande toto s’est bien passée, le return n’est pas exécuté,
sinon on quitte le module en cours pour rendre la main au module appelant, etc ..., etc ...
jusqu’à ce que le module appelant soit le script Ncooker, qui lui fait un exit avec le code d’erreur.

Les fontions de traitement d’erreur utilisent les fonctions du gestionnaire de messages.

error.sh
error.sh is used to set several error type to catch those errors and perform an action when they occure.

Utilisation de codes d’erreur et de variables pour les codes.

Pour éviter les nombres magiques, il y aura des codes d’erreurs.
Par exemple, si Ncooker a besoin d’être root, il faut qu’il le teste. Une fonction créée à cet effet (un script dans functions.d/ car elle peut être appelée de plusieurs modules) va tester si on est root, et renvoyer ok (0) ou un code d’erreur E_NOTROOT.

Cela permet de séparer le code de la gestion d’erreurs, par exemple en utilisant les trap (équivalent des exceptions du C++ ou java).
La fonction qui va récupérer l’erreur affiche un texte associé, car l’erreur sera unique, d’ou l’importance des retours de fonctions/scripts.

messages.sh
messages.sh is used to print out several type of messages (Infos, Errors, Warnings...) and perform a log management of this messages.

params.sh
Params.sh is an parameters analyzer specifically developed for Ncooker’s modular architecture.
Params.sh provides a mechanism to handle parameters provided to a command, or a module, but also to its dependencies (other commands and/or submodules used by this command/module).
This mechanism requires that any command/module using command line parameters has a configuration file named “params.conf” in its <command>.d or <module>.d directory.

Les commandes doivent permettre une utilisation intuitive de Ncooker, sans obliger à aller voir la page de manuel à chaque utilisation.

Ncooker <commande> <options> paquet1 paquet2 ...

A chaque commande correspond une fonctionnalité, une suite d’options, dont certaines sont utilisées par défaut, d’autres configurables dans Ncooker.conf.
Une commande devra correspondre à l’utilisation la plus courante pour un utilisateur lambda pour la fonctionnalité correspondante.
On peut imaginer d’autres fonctionnalités, mais l’important est de ne pas se disperser et étendre les possibilités d’une commande avec ses options.

Cette commande n’est pas encore écrite.

Ncooker config

Cette commande permet de connaître et de modifier toute la configuration de Ncooker : paramètres de Ncooker.conf (global et utilisateur), providers de paquets, miroirs pour les archives sources, ...
Bien sûr, ceci n’empêche absolument pas un utilisateur de modifier sa configuration avec son éditeur préféré.

Cette commande est écrite.
Getpkg is a Ncooker command aimed to manage packages retrieval.
Successfully retrieved files are listed in GETPKG_RESULT variable.

Ncooker getpkg

Getpkg est la commande utilisée pour récupérer les sources.
Check if given package is in Ncooker cache and may be read.
Try to retrieve package from cache if possible.
Set the GP_DEST_DIR variable to the right cache directory for the given package.

Suiavnt ce qui est passé sur la ligne de commande, getpkg va se comporter différemment :

• nom de package avec ou sans chemin

On regarde d’abord en local.
Si un chemin est passé, on vérifie juste que le fichier existe.
Si le chemin n’est pas passé, on vérifie si le fichier existe dans le répertoire courant, puis dans $NC_NBUILDS_DIR - le répertoire des Nbuilds de Ncooker.
Si le fichier n’est toujours pas trouvé, il va être récupéré chez un provider de paquets, ce qui peut amener soit à le télécharger si c’est en provider en ligne, soit à le récupérer sur un média local tel qu’un CD.

• nom de package sous forme d’URI (http://... , ftp://,... )

On regarde d’abord en local dans $NC_NBUILDS_DIR, sinon récupération auprès d’un provider local ou en ligne (appel download)

Dans les deux cas précédents, le téléchargement peut être forcé ou non, en option par défaut dans Ncooker.conf (nom de la variable non encore défini), ou en forçant avec l’option –force-download en ligne de commande.
Si pour une raison quelconque, l’utilisateur veut absolument télécharger le paquet, quand bien même il serait dans le cache, il peut utiliser l’option –force-download.

Si l’utilisateur lance “Ncooker getpkg package-1.0”, Ncooker va rechercher les paquets dont le nom commence par package-1.0 à plusieurs endroits :

• dans son cache, donc $NC_NBUILDS_DIR
• chez les providers

et il pourra lister tous les paquets correspondants afin que l’utilisateur puisse faire son choix.

Si le paquet (nbuild ou nba) est récupéré, il est placé dans le répertoire courant. On peut forcer cela en passant –dest-dir

On a donc pour le module getpkg : Ncooker getpkg [–dest-dir=<rep>] [–force-download] [–binary|–source] <package> [ <package> ... ]

Attention par contre, si on spécifie plusieurs packages sans extension, on ne peut pas combiner les nbuilds et nbas (soit la config par défaut, soit –binary, soit –source).

Cette commande n’est pas encore écrite.
La commande build est utilisée pour compiler et travailler avec les nbuilds.
Exemple :

Ncooker build foobar

Recherche le nbuild et le compile en un nba.
Par défaut le nbuild ira chercher toutes les sources nécessaires si elles ne sont pas déjà présente et sauf si on lui dit le contraire avec l’option –no-sources.
Pour ce qui est du rapatriement du nbuild, les options seront identiques à celles utilisées dans Ncooker install.

Quelques options possibles :

Ncooker build --skip configure make foobar

qui est le comportement actuel des options skip

Ncooker build --start 
Ncooker build --stop 

qui indiquent à quelles étapes commencer et finir la construction du paquet. Par exemple :

Ncooker build --start make --stop install foobar-1.0-nga1.nbuild

commence la construction à partir de do_make() et s’arrête après do_install(). Très pratique durant l’élaboration d’un nbuild.

Cala peut se combiner avec –skip :

Ncooker build --start make --stop install --skip preinstall foobar-1.0-nga1.nbuild

réalise toutes les étapes entre do_make() et do_install() sauf do_preinstall().

Ncooker build --help-configure foobar

qui renvoie toutes les options de la fonction do_help, ou encore :

Ncooker build --configure-options="<les options>"
Ncooker build --premake-options="<les options>"
Ncooker build --make-options="<les options>"
Ncooker build --preinstall-options="<les options>"
Ncooker build --install-options="<les options>"
Ncooker build --postinstall-options="<les options>"

ce qui donne :

Ncooker build --configure-options="--with-gtk --with-no-perl" foobar

Ncooker build --with-gtk --with-no-perl foobar (selon les options récupérées ci-dessus)

Ncooker build --install --with-gtk foobar

Liste à compléter !!
Vous l’aurez compris, Ncooker build sera la commande préférée du geek.

build se décline en plusieurs étapes de second niveau :

• getsrc : téléchargement et vérification des archives sources
• extract : décompression des archives sources
• pre-configure
• configure
• pre-make
• make
• pre-install
• install
• do-package

Elles ne peuvent pas être invoquées directement comme commande de Ncooker, mais pourront être manipulées par des options. Exemple :

 
Ncooker build --only getsrc foobar

ne fera que télécharger les archives sources du nbuild foobar.

De cette manière, le simple fait de taper :

Ncooker install foobar-1.0-nga1.nbuild

va faire appel au module install, qui automatiquement va faire appel au module build, qui à son tour va faire appel au module get.
A charge pour chaque module de savoir s’il doit réaliser ou non son travail. Par exemple, le module get vérifie si le paquet est déjà en local avant de commencer tout téléchargement.

Pour certains paquets, il n’est pas nécessaire de fournir un fichier build pour générer un paquet NBA.
L’idée est de séparer en plusieurs paquets NBA le résultat de la compilation pour que l’utilisateur final n’installe que ce qui lui est réellement utile.

Les comportements par défaut sont codés sous forme de sous-module de la commande build. Chaque sous-module correspont à une chaine de compilation donnée. Ncooker détecte automatiquement quel sous-module utiliser en fonction des fichiers trouvés dans les archives sources.

Définir un comportement par défaut revient en fait à écrire un fichier build avec les fonctions do_patches(), do_config(), do_make(), do_check(), do_install() et do_packages(), et à le placer dans un sous-répertoire de la commande build pour qu’elle puisse l’utiliser.
À partir de là, il suffit d’écrire un fichier build pour chaque chaîne de compilation que l’on veut gérer par défaut, en le nommant de manière adéquate : un fichier « gnu » pour les outils automake/autoconf, un fichier « scons » pour les outils scons, un fichier « ant » pour l’outil Ant, etc.

Pour que Ncooker puisse déterminer quel fichier il doit utiliser, chacun d’eux pourrait comporter une fonction supplémentaire nommée do_detect(). Cette fonction analyserait les scripts de compilation et retournerait 0 ou 1 pour indiquer si oui ou non elle sait les prendre en charge.

Cette commande est écrite.
Pack is a Ncooker command aimed to create Nbuild packages. Check if directories are given.

Ncooker pack

Remove the temporary directory defined in the ${g_sTempDir} variable.

Le nom et mail de l’auteur, configurés dans Ncooker.conf (NC_PKG_AUTHOR), sont automatiquement ajoutés au fichier infos.
Les sources du logiciel sont téléchargées dans le cache de Ncooker, le md5sum vérifié et ajouté automatiquement au fichier infos.
Enfin le nbuild est créé.

Cette commande n’est pas encore écrite.
On utilise cette fonction pour installer un ou plusieurs paquets, nba ou nbuild.
Le paquet peut-être sur le disque local, ou provenir d’un provider quelconque (cdrom, internet, clef usb, etc...).

Ncooker install

Pour spécifier un nba on utilise l’option

--binary (-b) ou --source (-s) 

Pour spécifier un nbuild on utilise l’option

--source (-s)

Le comportement par défaut serait :

• si le fichier passé est un nbuild, –source par défaut,
• si le fichier passé est un nba, –binary par défaut,
• si ambiguité, l’option par défaut de Ncooker.conf sera utilisée,
• dans ce même cas, l’utilisateur peut forcer –binary ou –source pour passer au dessus de la config par défaut,

cela réduit le pourcentage de fois où il faudra préciser –source ou –binary.

- Ncooker install foobar-1.0.nba

Si le paquet foobar-1.0.nba est présent dans le répertoire courant alors c’est lui qui est pris en compte.
Pour installer un paquet qui se trouve sur le disque autre part que dans le répertoire courant on spécifie le chemin : Ncooker install /home/toto/nba/foobar-1.0.nba
Il faut spécifier le nom complet d’un paquet si on veut que le paquet local soit choisi ; ce n’est pas contraignant grace à la bash_completion, en pratique ça revient à faire : Ncooker install foobar<tab>
Si le paquet foobar-1.0.nba n’est pas présent dans le répertoire courant alors Ncooker va chercher dans le provider par défaut qu’aura configuré l’utilisateur.

- Ncooker install foo

Là Ncooker ira chercher chez le provider par défaut un paquet dont le nom correspondra à foo et proposera une liste s’il y a plusieurs solutions.

bash_completion nous permettra de faire une complétion dans le cas ou aucun paquet foo ne match la complétion dans le répertoire courant.

A prévoir une option permettant de choisir un autre provider que celui choisit par défaut, par exemple :

Ncooker install --provider "nbuild.org" foobar

Le comportement par défaut sera d’installer les dépendances non satisfaites en même temps.
Une option permettra de ne pas vérifier les dépendances runtime.

Voilà pour le comportement général de Ncooker install.
D’autres d’options :

Ncooker install --upgrade foobar
Ncooker install --downgrade 1.0 foobar
Ncooker install --upgrade

Check is a Ncooker command aimed to verify packages validity. Cette commande est écrite mais va beaucoup changer avec l’utilisation du schéma XML. A développer ...

Ncooker check

Les vérifications effectuées sont :

Compare two package versions
Sort the specified range of an array containing package versions in ascending order, using the quicksort algorithm.
Try to retrieve the content of <filename> stored in a package or a directory, and checks if it contains instructions, i.e. something different from comments (#) and blank lines.
Check if code block passed in parameter is syntaxically correct.
Check the validity of an ‘infos’ file contained in a package or in a directory.
Check the validity of a ‘build’ file contained in a package or in a directory.
Check the validity of a ‘desc’ file contained in a package or in a directory.
Check the validity of a ‘changelog’ file contained in a package or in a directory.

Cette commande n’est pas encore écrite.
Cette fonctionnalité permettra de rechercher dans les index des providers des paquets selon différents critères (nom, mots clés,...).

Ncooker search

Ncooker search foo

Cherche tous les paquets dont le nom contient foo

Ncooker search --keywords mail client web

Cherche tous les paquets dont le keyword contient mail client et web

Cette fonctionnalité devra être travaillée en relation avec le travail de Gontran sur la catégorisation des paquets.

Cette commande n’est pas encore écrite.
Cette fonction permet d’avoir des infos sur un/des paquets, ou sur tout le système en particulier. Zxemple :

Ncooker info foobar

affichera par défaut toutes les infos possibles sur foobar (fichier info du nbuild, qui le provide, si installé ou non, etc...)

Après on peut choisir des infos particulières :

Ncooker info --up-to-date foobar

pour savoir si foobar est à jour

Ncooker info --up-to-date

pour lister tous les paquets qui ne sont pas à jour (c’est à dire pour lesquels une nouvelle version est disponible)

A compléter ...

Cette commande n’est pas encore écrite.

Ncooker remove

Cette commande n’est pas encore écrite.
Cette fonction permet de gérer les providers de paquets (ajout, mise à jour, suppression).

Ncooker provider

Les options :

Ncooker provider --add http://nasgaia.org nasgaia
Ncooker provider --add http://foobar.org foobar
Ncooker provider --remove foobar
Ncooker provider --list
Ncooker provider --update nasgaia
Ncooker provider --update

Cette commande n’est pas encore écrite.

Ncooker wizard

Si on lance simplement « Ncooker wizard », une série de questions est posée à l’utilisateur pour créer un répertoire avec les fichiers infos et build, puis générer un nbuild automatiquement.
Si on lance « Ncooker wizard –files toto », un répertoire toto est créé avec un modèle de fichiers infos et build, que l’utilisateur devrait compléter à la main.

Les commandes check, pack, build et remove effectuent plusieurs contrôles sur les fichiers contenus dans les paquets.

chaque module devra tester (si besoin uniquement) si Ncooker a été lancé en tant que root.
Une fonction globale généralisera le code. Si on a besoin d’être root et que ce n’est pas le cas, le module sera relancé en su (ou sudo suivant config). Les modules appelés depuis ce point (par exemple install lance d’abord build, qui fera la vérification) feront le test mais seront déjà root (car on va y rester jusqu’à la fin du module).

Cel permet de simplifier cette gestion tout en permettant de passer root si besoin, facilement, en ne le faisant qu’une fois pendant toute la durée de la commande.

download.sh
This module handles all types of downloads needed by Ncooker.
Check if an URL is syntaxically valid.
Check if the protocol used by the given URL is handled by the Ncooker Dowload module.
Check if errors occured with some URLs and print the associated error messages.
Check if protocols are available.
Check if URIs are given.

getsrc.sh
GetSrc is a Ncooker module aimed to handle sources archives downloads.
Set options as positional parameters to correctly handle quoted arguments.
Check if URIs are given.
Set found operands as positional parameters to correctly handle quoted arguments.
If download isn’t forced, check if package is available in cache.
Run Download module, passing it the full list of alternative urls to + download the sources archive.

uncompress.sh
This module handles all types of archive decompression needed by Ncooker.
It checks if the archive contains only one directory at its root. If this is not the case, it uses archive name without extension to create a sub-directory in destination dir (${UNCMP_DEST_DIR}) and uncompress archive content inside.
Check if unarchivers are available.
Set options as positional parameters to correctly handle quoted arguments.
Check if archives are given.
Set found operands as positional parameters to correctly handle quoted arguments.

A chaque paquet sera affecté un ou plusieurs mots clef (descripteurs) selon une liste prédéfinie.
Descripteurs Ncooker
La liste des nodes

Les branches principales sont :

indique la nature des éléments contenus dans un paquet

indique le type d’interface utilisateur d’une application (pour une librairie, il n’y a pas d’interface utilisateur)

domaine auquel se rapporte les éléments contenus dans un paquet

types de données utilisés par ces éléments

la ou les fonctions de ces éléments

public auquel sont destinés ces éléments

Un outil permettant d’être alerté automatiquement des nouvelles versions des logiciels est indispensable.
Cela contribue à améliorer notre réactivité pour les mises à jour des paquets sans avoir à surveiller « activement » les sites webs correspondants.

Convert is a Ncooker tool to convert NBUILD packages from Nasgaia 1.0.1 to the new Ncooker NBUILD format.

convert.sh <nbuild_package...>

The goal of this tool is to check that the new modifications made to the code of Ncooker do not affect the existing functionalities.
There are actually 137 individual tests concerning the Getpkg and Check commands.

La variable d’environnement LANGUAGE doit être initialisée avec votre langue.
Vous pouvez faire export LANGUAGE=fr par exemple pour avoir Ncooker en français.
Pour que cette valeur reste appliquée entre sessions, il faut la définir dans le fichier /etc/profile en ajoutant une ligne export LANGUAGE=fr (variable selon distribution).

Il y a plusieurs étapes de traduction :

1. Extraire les messages de Ncooker
2. Traduire les messages
3. Installer la traduction

Le rôle du développeur est de faciliter la traduction de son travail par les traducteurs.
Pour cela on peut se fixer des règles simples :

• Centraliser ses messages (dans les fichiers messages.sh de chaque module)
• Utiliser gettext proprement.

Il est indispensable de tester ses messages pour voir s’ils s’affichent correctement.
Effectuer des tests de traduction pour voir si tout se passe bien.