From: "Julien L." <[EMAIL PROTECTED]>
Reply-To: Mailing list for dev purpose <[email protected]>
To: [email protected]
Subject: [Nasgaia-dev] [Ncooker] Tests - Première partie
Date: Mon, 07 Nov 2005 13:51:35 +0100
Bonjour tout le monde,
J'ai enfin réussi à installer Ncooker après avoir installé 7-Zip, libxml2,
libxslt et xmlstarlet (avec lequel je n'ai eu aucun problème). Je vous
passe les détails des moyens que j'ai employés pour faire cela. Je dirais
simplement que "split -b 1400k" est mon ami. ;)
J'ai donc pu effectuer quelques tests. Je vous livre ma découverte de
Ncooker, les problèmes que j'ai rencontré, les questions que je me suis
posé. Sur chaque point, je veux bien avoir votre avis et me dire si il vaut
la peine de saisir une anomalie dans le bug tracker.
Installation et configuration
-----------------------------------------------------------
L'installation de Ncooker en lui-même ne m'a pas posé de problème
particulier.
Je me suis d'abord penché sur la commande config. Je lance "Ncooker config"
et là, rien ne s'affiche. "echo $?" m'indique 0. Une première question se
vient à moi : est-ce correct que l'aide de la commande config ne s'affiche
pas ?
Je lance la commande "Ncooker config --root /tmpsys" et rien ne se passe.
Cette fonctionnalité est-elle implémentée ? Si oui, quelle est son
comportement ? (mêmes questions pour l'option --dbpath)
Je finis par lancer "Ncooker config --initdb" en tant que root. Tout se
passe bien.
Commande wizard
-----------------------------------------------------------
En tant qu'utilisateur simple, je lance "Ncooker wizard" et je reçois
l'erreur suivante :
Ncooker: throw : unhandled error NO_PACKAGES_GIVEN (fatal error)
Ne devrions-nous pas plutôt avoir l'usage de la commande "wizard" à la
place ?
Je regarde l'usage de la commande "wizard" et je me pose une nouvelle
question : pourquoi avons-nous l'option "--template" ? Pourquoi ne pas
avoir directement le nom du package à créer en argument de la commande ?
Cela me paraîtrait plus naturel.
Je génère un premier répertoire nbuild.
Fichier infos
-----------------------------------------------------------
Le fichier infos est fort bien commenté. Il semble qu'un effort ait été
fait afin que les commentaires ne dépassent pas 80 caractères par ligne.
Malheureusement, quelques lignes présentent 81 caractères (80 caractères
pour le texte et 1 pour le retour à la ligne). Ces lignes sont : 33, 53,
73, 76, 93, 110, 125, 130, 133.
J'ai noté quelques fautes d'orthographe/grammaire/expression. Avant tout,
je voudrais faire un petit point sur le mot anglais "information". Ce mot
est invariable. Cela signifie qu'on ne peut pas le mettre au pluriel. De
plus, il désigne une généralité. En fait, c'est comme le mot "paper". Pour
parler de ce qu'on appelle en français "une information", il faut écrire "a
piece of information" (de la même façon qu'on écrit "a piece of paper").
Voilà pour la théorie. Dans notre cas, je pense qu'il faut remplacer
"informations", selon les cas, soit par "information", soit par "pieces of
information".
Par la même occasion, je me demande si il est correct d'appeler ce fichier
"infos" puisque le mot anglais "informations" n'existe pas. Le mot "desc"
serait peut-être plus approprié.
Voici les fautes que j'ai notées :
- à la ligne 45, il faut remplacer "must provides" par "must provide" ;
- aux lignes 46 et 51, il me semble qu'il faut mettre une majuscule aux
noms de langue (ici, "French" et "English") ;
- à la ligne 52, il faut remplacer "is explains" par "is explained" ;
- à la ligne 53, on ne peut pas écrire "the software" dans le cas précis ;
c'est la même chose que le mot "information" ; "the software" désigne le
logiciel de façon générale, de la même façon qu'on parle du matériel ("the
hardware") sans préciser quel composant il s'agit précisément ; il faut
donc plutôt écrire "the piece of software".
- à la ligne 73, il faut remplacer "defines" par "define" ;
- à la ligne 130, il faut remplacer "be see" par "be seen" ;
- à la ligne 144, il faut remplacer "relates" par "relate".
A la ligne 76, on nous parle d'un fichier NcookerTroveNodes. Est-ce que ce
fichier existe encore ? En tout cas, je ne l'ai pas trouvé dans le
répertoire indiqué sur mon système.
D'après ce que j'ai compris, la balise <file> permet de préciser le nom du
fichier ressource et les balises <location> permettent de fournir une liste
des "répertoires" distants où pourra être téléchargé le fichier ressource.
Exemple :
<file name="qiv-$VERSION-src.tar.gz">
<location>http://qiv.sourceforge.net/qiv/</location>
<!-- ... other locations may be added for this file ... -->
</file>
Je me demande si ce système prévoit le téléchargement à une URL ressemblant
à la suivante :
http://www.qiv.net/download.php?version=2.0
Je ne sais pas si ce type d'URL est possible mais j'imagine que oui. Si un
tel cas existe, que dois-je mettre dans les balises <file> et <location> ?
Je propose la chose suivante. Si le répertoire distant finit par un slash,
on télécharge à l'URL <info de location><nom du fichier>. Si le répertoire
distant ne finit pas par un slash, on télécharge à l'URL <info de
location>.
Je suis un peu étonné de voir la balise <build>. D'après, ce que j'ai
compris, les informations spécifiées sous cette balise sont utilisées par
la suite dans le fichier build. Elles donnent à l'utilisateur les options
utilisées lors du configure/make/make install. Je trouve que c'est une idée
pas si bête que cela mais je crois que ces informations ne devraient pas
figurer dans ce fichier. Je vois plutôt ces informations d'une façon ou
d'une autre dans la primitive do_help.
Sous la balise <changelog>, on trouve une balise <release> servant à
décrire les changements effectués sur le paquet pour le couple "version du
projet/version du paquet". Or, une balise <release> existe déjà pour
spécifier la version du paquet. Je trouve qu'il y a une double confusion
avec cette balise <release>. D'une part, elle contient deux types
d'informations différents (un entier ou un texte "libre"). D'autre part,
elle désigne deux types de version différents (version du paquet ou couple
des versions). C'est pourquoi je propose de renommer la deuxième balise
<release> par <changes>.
Fichier build
-----------------------------------------------------------
Le fichier build est lui aussi fort bien commenté.
J'aurais quelques suggestions à propos des différentes étapes. Je trouve
qu'elle manque de clarté et de généricité. Selon moi, le création d'un
package peut être décomposée en cinq étapes :
- dépaquetage (do_unpack)
- configuration (do_config)
- construction (do_make)
- installation (do_install)
- empaquetage (do_package)
D'abord, je renommerais la dernière étape "do_pack" afin d'être
"symétrique" avec la première étape.
Ensuite, pour chacune de ces étapes, il est nécessaire d'avoir une étape
intermédiaire de préparaton (do_pre*) et de finalisation (do_post*). Bien
sûr, pour la première étape, la préparation n'a pas vraiment d'utilité
(avant d'avoir décompressé le paquetage source, que peut-on faire ?). De
même, pour la dernière étape, l'étape de finalisation est inutile (après
que le package soit créé, que peut-on faire de plus ?).
C'est pourquoi je propose la liste des étapes suivante :
- do_unpack (tel qu'il existe déjà)
- do_postunpack (qui remplacerait do_patches pour plus de généralité)
- do_preconfig (tel qu'il existe déjà)
- do_config (tel qu'il existe déjà)
- do_postconfig
- do_premake (tel qu'il existe déjà)
- do_make (tel qu'il existe déjà)
- do_postmake (qui remplacerait do_check pour plus de généralité)
- do_preinstall (tel qu'il existe déjà)
- do_install (tel qu'il existe déjà)
- do_postinstall (tel qu'il existe déjà)
- do_prepack
- do_pack (qui remplacerait do_package)
Cela peut sembler faire beaucoup d'étapes mais je pense que cela rend
encore plus générique la construction du paquet. Cela permet donc d'avoir
une plus grande flexibilité pour l'ensemble des packages qui peut exister
dans le monde. D'autre part, il faut garder à l'esprit qu'une étape est
maintenant optionnelle dans un fichier build. Ainsi, le développeur peut se
passer d'écrire toutes les étapes do_pre* et do_post*. Si le développeur a
besoin de lancer des instructions supplémentaires entre un "./configure" et
un "make", il pourra les écrire dans do_postconfig ou do_premake, selon
qu'il considère que ses instructions sont plutôt de la finalisation à la
configuration ou plutôt de la préparation à la compilation. Cela donne
donc, de mon point de vue, plus de liberté au développeur.
Dans le fichier build généré, on voit que des fonctions sont appelées
(create_nba ou strip_fakeroot_objfiles par exemple). Etant donné que ces
fonctions sont fournies par Ncooker, je les préfixerais par "ncooker_". De
la même façon, je préfixerais les variables (comme PKG_FAKEROOT_DIR) par
"NC_".
Dans les commentaires de l'étape do_postinstall, on dit que cette étape est
dédiée à l'installation des fichiers de documentation (entre autres). J'ai
deux questions à ce propos :
- sous Nasgaïa 1.0.1, cela était fait dans l'étape do_preinstall. Y a-t-il
une différence à réaliser l'installation de la documentation à l'étape
do_preinstall ou do_postinstall ?
- sous Nasgaïa 1.0.1, il existait une fonction add_doc. Y a-t-il une telle
fonction dans ce nouveau Ncooker ? Si oui, il serait intéressant de donner
un exemple d'appel dans le fichier modèle.
Toujours dans do_postinstall, on donne un exemple d'installation d'une
ressource annexe en faisant appel à la commande "cp". Je pense qu'il
faudrait ajouter un appel à la commande "chmod" pour positionner les
droits. Mieux, il serait plus judicieux de faire appel à la commande
"install" qui copie et positionne les droits. Il serait aussi utilie de
donner un exemple de création de répertoire dans le fakeroot (avec la
commande "install -d").
Commande pack
-----------------------------------------------------------
En tant qu'utilisateur simple, je lance la commande "Ncooker pack .". Une
erreur m'indique que le répertoire
/var/lib/Ncooker/packaging/nbuilds/qiv2-2.0-nga1 ne peut pas être créé. Je
paramètre donc ce répertoire dans mon fichier de configuration personnelle.
Je relance la commande et c'est maintenant le répertoire
/var/cache/Ncooker/resources/qiv2-2.0 qui ne peut pas être créé. Je modifie
encore une fois le fichier de configuration.
J'arrive enfin à créer mon nbuild. Je le désarchive pour vérifier son
contenu. Des informations ont bel et bien été ajoutées au fichier infos,
notamment au niveau de la balise <changelog> :
<changelog>
<release version="2.0-nga1" author="Julien Lesouef
<[EMAIL PROTECTED]>" date="2005-11-06T19:29:46Z">
- first release of the stable version.
</release>
</changelog>
Deux remarques :
- la date ajoutée possède un drôle de format. Est-ce correct ?
- la balise de fin </release> est décalée par rapport à son indentation
prévue.
Je remarque que le fichier a été reformaté avec une indentation de deux
caractères. Je pense que cette même indentation pourrait être appliquée au
fichier modèle infos.
Voilà pour aujourd'hui. Je continuerai mes tests dans les prochains jours.
N'hésitez pas à réagir aux différents points que j'ai abordés.
Pour finir, je tiens à remercier Gontran pour ce magnifique travail. C'est
vraiment du beau boulot. Ces derniers jours, j'ai écrit quelques Nbuilds
pour ma Nasgaïa 1.0.1 et je sens que ce nouveau Ncooker va me faciliter la
vie. :)
--
Julien L
_________________________________________________________________
Tout savoir sur la sécurité de vos enfants sur Internet !
http://go.msn.fr/10-channel/80-security/protection/default.asp
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
