Le Samedi 3 Septembre 2005 21:54, le guillerm sebastien a écrit : > voilà , la base de Ndeveasy est presque finie ou est déjà exploitable. > > on peut donc commencer à discuter de son module "Package".
On peut, mais le nouveau format des paquets n'est pas validé. S'il évolue par la suite, il faudra adapter le module Package de Ndeveasy aux changements apportés. Il faut que le développeur de ce module en ait conscience. :-) > Voilà comment je l'imagine : > > - des onglets > - une zone affichages et de saisies > > Premier onglet : > ---------------- > > Edition du Nbuild : > > (on charge un Nbuild vide et avec des regex pourra l'éditer facilement) Par "nbuild vide", tu veux dire un fichier "infos" vide comme celui généré par la commande "Ncooker wizard --template" ? Dans ce cas, pas besoin de regex. C'est un fichier XML, et Ruby doit avoir des fonctions pour le manipuler directement. > Ici on dispose d'autant de zone de saisie que de variable dans le Nbuild. > > Cela pourrait être de la forme : > nom du paquet : zone de saisie > version du paquet :zone de saisie > etc ... > > au bout de la zone de saisie un petit icone qui charge la partie de la doc > (de ngadoc sur Ncooker) correspondant à l'entrée en cour. > > > deuième onglet : > ---------------- > > Vérification de la syntaxe : > ici on fait appel à la commande check de Ncooker. > Une boite de dialogue indique des OK ou fail pour chaques tests de la > commande Check de Ncooker (au pire une serie de regex pour identifier quel > test passe ou ne passe pas). La solution simple est d'afficher la sortie de la commande Check directement dans le module, mais on peut aussi faire beaucoup plus "travaillé". :-) Chicha est en train de se pencher sur la nouvelle gestion des messages, et ça pourrait être utile que les messages d'erreurs indique le nom du fichier et la ligne fautive. Par exemple : infos:6:invalid format for the project version '-1.0' Une regex permettrait de séparer les éléments et de déterminer que l'erreur se trouve à la ligne 6 du fichier infos. Reste à voir comment se fait le lien entre l'erreur et le champ de saisie de l'onglet 1 :-) > De même ici il est possible d'accéder à la doc Ncooker pour connaitre la > fonction exacte de chaques test. > > > troisième onglet : > ------------------ > > ./configure > > ici on télécharge , et extrait le paquet grace à la commande de Ncooker > déjà prévu à cet éffet. ensuite on lance ./configure -h pour visualiser le > contenu. on télécharge et extrait les "sources", pas le paquet :-) Sauf qu'il n'y a pas de commande Ncooker pour faire ça. Il y a le module Uncompress, mais c'est un module, pas une commande, et il n'est donc pas utilisable directement depuis la ligne de commande. De plus, le "./configure -h" va marcher pour 90% des paquets parce qu'ils utilisent la chaine de compilation GNU "./configure; make; make install". Mais pour ceux qui ne l'utilisent pas, non. Ce n'est pas encore géré, mais le script build des paquets Nbuild peut avoir une fonction do_help() pour afficher des infos sur les options utilisables avec les étapes do_config, do_make et do_install. Ce sera au nbuildeur de renseigner la fonction do_help() en y plaçant un "./configure --help" si c'est approprié, ou toute autre commande permettant d'afficher ce type d'informations (cat README, cat INSTALL, etc). Ensuite, la commande Build de Ncooker permettra d'invoquer cette fonction. Par exemple : $ Ncooker build --info paquet.nbuild provoquera le téléchargement des sources et leur extraction, puis exécutera la fonction do_help(). S'il y a "./configure --help" dans le corps de cette fonction, il sera affiché les options utilisables avec l'étape do_config. > On peut aussi imaginer en bas de la fenètre uen zone de saisie pour y > copier directement les options du ./configure pour pouvoir personaliser le > paquet en direct. > > > quatrième onglet : > --------------------- > > construire le paquet : > ici on construit le paquet mais on l'installe pas (Ncooker possède cette > option il me semble) Oui : $ Ncooker build --end-stage "make" exécutera toutes les étapes du processus de construction jusqu'à do_make, puis s'arrêtera. > > cinquième onglet : > ---------------------- > > voir le contenu du paquet : > > ici on install le paquet dans un répertoire particulié et le filelist > apparait. $ Ncooker build --stage "install" permet de n'exécuter que l'étape do_install, qui installe le logiciel dans un fakeroot géré automatiquement par Ncooker. Mais la fonction do_postinstall peut aussi compléter l'installation en créant des fichiers supplémentaires. Donc il faudrait aller jusqu'à --stage "postinstall". Remarques : - les onglets 3 à 5 ne permettent de gérer que trois étapes du processus de compilation alors que la commande build en propose une dizaine. - Je verrais plus un unique onglet avec une liste de cases à cocher pour sélectionner les étapes de construction à réaliser. - la commande build propose l'option --interactive qui permet de faire une pause entre chaque étape de construction et de demander une confirmation avant d'exécuter l'étape suivante. Le module Package de Ndeveasy pourrait l'exploiter pour se faciliter la tâche. > cela permet de prévoir ce qui va être installé sur le système. > > <c'est une étape primordiale !!> Oui, vérification indispensable. > ------------------------------------------------------- > > ensuite comme beaucoups de paquets nécesitent plusieurs recompilations ( on > peut à tout moment revenir en arrière gràce à un bouton "clean" et > recommencer, a voir dans la suite) il pourrait être utile de gérer une fonction do_clean() dans le fichier build ? Elle serait appelée entre les étapes do_unpack et do_config, et permettrait de lancer un nettoyage des sources en y plaçant un "make clean" ou tout autre instruction adaptée aux outils de compilation utilisé par le logiciel. > sixième, sept , ou même huitième onglet: > ---------------------------- > > ici c'est plus les onglets de personnalisations : > > On peut y éditer les fonctions patch, extract, ou post_install, remove etc > .. toutes les fonctions do_* du script build en fait ? Pourquoi ne pas placer cette étape après l'onglet 1 ? > Ces onglets ne sont donc que "rarement" utilisé > là aussi un bouton d'aide permet d'accéder à la partie de la doc Ncooker > qui correspond. ----------------------------------------- > > enfin, deux boutons : > > Installer et Nétoyer , qui permettent d'installer ou de vider le > repertoire où sont mis les sources. Mais bien sur cela n'éfface pas le > Build et les autres fonctions déjà remplie. Le but étant de faciliter les > recompilations et les modifications du Nbuild/nba. > ------------------------------------------ > En vrac : > > Peut être aussi une fonction vérification des MAJs des paquets gràce à une > liste de regex qui va chercher toutes seule la dernière version des paquets > sur le site (j'ai déjà bonne une liste) Oui, je n'ai pas oublié ton idée :-) Je ne sais pas encore s'il faut l'intégrer à Ncooker ou faire une appli à part, à débattre. > Une vérification post_install pour valider le paquets : > droits des fichiers > structure des répertoires > etc.. (si une vérif post_install n'est pas inclue dans Ncooker, car la > commande check vérifie la validité du Nbuild pas du paquet en lui même) Oui, Check n'est pas dédié à cette tâche. Mais on pourrait très bien mettre en place des tests de ce genre dans la fonction do_postinstall() du comportement build par défaut de Ncooker. Si tu as des idées précises de tests, je suis preneur. N'hésite pas à les développer :-) > Une fonction Upload du paquet sur le repertoire Incoming de nasgaia pour > les membres de la communauté souhaitant proposer leur paquet Ça, c'est à réfléchir mûrement. Il ne faut pas que tout le monde puisse mettre tout et n'importe quoi non plus. Y a-t-il un contrôle ou est-ce que c'est libre d'accès ? On a aussi parlé d'une équipe de validation des paquets. Comment est-ce que les deux se combinent ? > Un arbre de tous les ports disponibles (avec une mini-description) sur > nasgaia pour choisir le plus facilement/exactement la catégorie du paquet. Tu peux être plus précis stp ? :-) Un exemple de port et de catégorie de paquet ? > Un mode avancé est déjà prévu dans Ndeveasy avec une édition/modification à la main des fichiers en cas de besoins encore plus spécifiques. Les onglets 6,7 et 8 font partie du mode avancé ? Je trouve que le système d'onglets n'est pas forcément adapté pour ce type de tâche. Généralement, on utilise les onglets dans les boites de dialogue de configuration, pour regrouper les différentes options par catégories. Je verrais plus une succession d'étapes avec des boutons Suivant >> et << Précédent. ++ Gontran
