Salut Riri, Salut tout le monde,
> riri: En fait, c'est important dans la mesure où on s'attaque aux > mises à jour. Ce n'est bien-sûr pas le cas de manière générale, mais > il se peut que j'en ai besoin dans la construction du devkit : comme > on est toujours dans un processus de 'dernière version des paquets', > j'essaye de garder le devkit à jour au fur et à mesure qu'il avance. > Les paquets déjà installés peuvent évoluer pendant ce temps, et si je > n'ai pas de système de mise à jour, je peux avoir des problèmes de > fichiers écrasés, c'est tout. Donc non pas critique, mais souhaitable. > Par ailleurs, il faut bien penser que la mise à jour est quelquechose > d'aussi important (voire plus) que l'installation. Les développeurs de > pacman s'en sont rendu compte, à tel point que la commande > d'installation 'pure' est obsolète, et est replacée de manière globale > par la commande de mise à jour. L'expérience de pacman n'est pas > isolée à mon avis, et je comprends tout à fait les raisons de cette > décision. Jepense qu'on pourrait tirer partie de cette expérience. Je n'ai qu'une chose à dire : je suis d'accord avec tout ce que tu as écrit. ;) > riri: Je pense qu'il ne s'agit pas d'un problème de terminal. Ces > infos s'affichent très bien en sortie, mais sont affreuses en log. Le > même problème existe pour les couleurs, mais pour cela, Ncooker > dispose d'un inhibiteur. Ah d'accord. Tu constates cela dans des fichiers de traces. Ca doit être normal. Je vais essayer de penser à ajouter un inhibiteur, comme pour les couleurs. > riri: Parce que créer ou modifier un Nbuild est un processus très long > comparé à mon système de patron de nbuild, pour plusieurs raisons : > 1) je n'ai qu'un fichier à créer/modifier > 2) un bon nombre d'informations utiles à Ncooker pour empaqueter sont > déjà utilisées ailleurs dans Ndkm (les ressources par exemple), elle > sont donc réutilisées > > Je peux te conseiller de regarder le code de la gestion de Ncooker > dans Ndkm : > http://svn.gna.org/viewcvs/nasgaia/trunk/ndkm/src/ncooker.sh?rev=768&view=markup > ainsi que le contenu d'un patron classique, disons gawk : > http://svn.gna.org/viewcvs/nasgaia/trunk/ndkm/work/archives/nbuilds-templates/gawk?rev=771&view=auto > Ndkm utilise en même temps son fichier de ressources qui contient les > archives et patchs à utiliser : > http://svn.gna.org/viewcvs/nasgaia/trunk/ndkm/stages/resources.conf?rev=769&view=auto > > Un truc intéressant est l'utilisation de pseudo variables qui > simplifie les modifications (par exemple pour la version). Le fichier > changelog est aussi alimenté par substitution : > # changelog > changelog = {{{ > % @[EMAIL PROTECTED]@PROVIDER@@FIX@ Richard Gill @DATE@ > - first release of the package > }}} Ce que je crois comprendre, c'est que tu crées des nbuilds à la volée. C'est une façon de faire et je comprends que ça peut te faciliter la maintenance (peu de fichiers à maintenir par rapport a plusieurs nbuilds) mais, à un moment ou un autre, nous aurons besoin d'écrire ces nbuilds. Est-ce que je me trompe ? > riri: Je parlais du fichier "files" pour indiquer ça dans la base de > données, il est bien entendu que cette info doit d'abord se trouver > dans le fichier info pour dire à Ncooker de faire le marquage sur ces > fichiers. Pourquoi a-t-on besoin de cette info dans la base de données ? En tout cas, ces discussions montrent qu'il y a encore du boulot sur Ncooker. ;) @+ -- JulienL _________________________________________________________________ Comme 9 millions de français, créez un compte Hotmail ! http://www.windowslive.fr/hotmail/default.asp _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
