Le 07/11/05, Julien L.<[EMAIL PROTECTED]> a écrit :
> Bonjour tout le monde,
Rebonjour Julien :-p
Bon j'ai un peu plus de pistes concerant Ncooker,
et je vais tenter donc de commencer a repondre a tes differentes remarques :
Si tu vois des inexactitudes Gontran, n'hésite pas à me reprendre :-)
> 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. ;)
Disquette powa :-)
> 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.
Je vais donc donner mon avis, ou en tout cas
ce que j'ai compris de la vaocation de Ncooker
> 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 ?
Correct, oui, ce n'est pas prévu :-p
Par contre, je suis tout a fait d'accord sur le fait que dans
ce cas on devrait obtenir l'aide de la commande,
ce qui est naturel selon moi. Si personne n'a d'objections,
je m'en occupe.
> 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)
Oui elle est implementee dans le code de config.sh, et elle ajuste
CONFIG_ROOT_DIR et par ricochet CONFIG_DB_DIR en consequence
par contre, le reglage reste "live" et non stockée
--> a mon avis a essayer en conjonction avec d'autres commandes
> Je finis par lancer "Ncooker config --initdb" en tant que root. Tout se
> passe bien.
Chez moi aussi ^^
> 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
> ?
Meme remarque que pour config, je suis aussi d'accord avec toi
sur ce point
> 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.
C'est sur que ce serait plus intuitif, mais --template a selon moi
l'avantage de te donner une base generique sur laquelle travailler, a
debattre...
> 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".
Pour les corrections d'orthographe, pas de problemes pour moi..
Qui est contre les corrections ? :-p
> 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.
Oui il s'agit de l'arborescence des Nbuilds accessible sur le wiki :
http://winuxien.free.fr/NcookerDescriptors2.html,
selon moi : pas encore implementé mais déjà prévu.
> 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> ?
a priori, je laisserait <file> vide, mais c'est vrai que ça pose pb,
caron ne connait pas alors le no du fichier a decompresser...
--> modification de la balise <file> ?
> 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>.
Certes mais ça ne regle pas le pb que je viens d'evoquer
> 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.
C'est vrai que si jai compris gontra, c'est pour pouvoir faire des modifs
minueres au niveau des parametres sans toucher a build.
Apres, je suis d'accord avec toi sur le fait que ce n'est pas
forcement leur place
--> je les vois aussi pus dans build, pour etre logique
> 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>.
Pour moi pas de probleme
> 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.
pour moi, proposition retenue, des objections ? :-p
> 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.
Personnellement ta liste detapes me convient parfaitement,
meme si elle est un peu longue la plupart des fonctions etant de toute
façon optionnelles, cela ne devrait pas se ressentir dans les paquets
"normaux"
et etre bien utile pour ceux plus tarbiscotés niveau mise en place
> 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_".
On y gagne en lisibilité, pour moi ok
> 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.
Pas encore regardé, ça vient :-)
> 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").
Tres bonne remarque, effectivement ça peut nous eviter bien des tracas
> 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.
Je teste ça des que possible, pb de droit ou Ncooker
ne les cree pas par defaut ?
> 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.
Pour ce qui est de la date, effectivement le format est brut
et peut sembler bizarre, il faudrait sans doute reformater la chose
du genre date="2005-11-06 19:29:46" en mettant l'heure a l'heure universelle
Pour ce qui est de </release> et de son indentation, doit etre un petit
pb dans le template : je corrige des que possible
> 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.
Effectivement, ce serait beaucoup plus logique
> 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. :)
Moi aussi, moi aussi :-p
Merci Gontran :-D
@+ Julien
guiguilinux
