Richard,
>OUi tu as bien compris le problème. Il s'agit peut-être d'un problème
>du filtrage (j'avoue je pas avoir vérifier le code de gendeps.sh). Il
>faut quand même noter que l'on est dans un cas particulier, car ces
>libs sont à la fois sur le système et fournies par le paquet, est-ce
>que cela pourrait gêner le filtrage ?
Je ne sais pas. Il faudrait se mettre en debug sur gendeps.sh, et en
particulier sur cette section :
declare g_sFoundFile=$( find "$g_sBinaryTree" -printf '/%P\n' \
| grep "/$g_sDependency$" )
if [ -n "$g_sFoundFile" ]; then
continue
fi
unset g_sFoundFile
Il faudrait ajouter des "echo" au dessus, au milieu, en dessous pour
vérifier si le filtrage est bien réalisé.
>Quoi qu'il en soit, je maintiens qu'une fonction de surcharge dans le
>fichier build, juste avant la création du nba, serait intéressante,
>comme expliqué hier soir sur le chan. Je résume pour ceux qui
>n'étaient pas là :
>
>Pour l'instant, dans le fichier build, on peut surcharger la fonction
>do_package(), qui appelle par défaut npkg_create_nba(). Cette
>fonction, en plus de gérer les suppressions de répertoires temporaires
>et la création du data.t7z, génère les fichiers propres au nba (files,
>product et fulldeps). On ne peut donc pas intervenir entre ces
>générations et la création du fichier .nba.
>
>L'idée serait de pouvoir le faire. Il existe un stage 'prepackage'
>(géré par la fonction do_prepackage()) situé entre les stages
>'postinstall' et 'package'. On pourrait donc déplacer les générations
>de fichiers dans ce stage (qui aurait alors un comportement par
>défaut, alors qu'aujourd'hui, il ne fait rien). C'est une idée de
>Julien, car j'avais d'abord pensé à créer une autre fonction
>surchargable.
>
>Maintenant pour la surcharge on a deux possibilités:
>1) appeler une fonction similairement à npkg_create_nba() qui effectue
>ces traitements, et derrière faire tout ce qu'on veut
>2) appeler une fonction par fichier généré, par exemple
>npkg_gen_fulldeps(), npkg_gen_files() et npkg_gen_product(). On est
>alors libre d'appeler les fonctions que l'on veut, et après de faire
>tout ce qu'on veut
>
>J'ai une préférence pour la solution 1, car c'est plus simple d'emploi
>et ressemble à do_package() avec son npkg_create_nba() (une fonction
>qui faire le traitement par défaut). La solution 2 a elle l'avantage
>d'être plus souple, mais dès qu'on surcharge do_prepackage(), il faut
>alors choisir les fonctions appelées. Un point positif pour la
>solution 2 est que les noms de fonctions à appeler sont faciles à
>déterminer (comme l'exemple que j'ai donné), pour la solution 1, je
>n'ai pas encore trouvé de nom 'parlant' :-)
>
>Julien, est-ce que ça résume bien le problème et la solution proposée ?
Ben pour moi, le problème reste à déterminer.
Je reconnais néanmoins qu'il peut y avoir amélioration sur le sujet. Dans ma
tête, il y a 4 solutions (une que tu as volontairement omise, deux que tu
viens de décrire et une qui m'est apparue ce matin).
Malheuresement, je n'ai pas le temps de les décrire (je travaille, môa,
monsieur ! ;) ). J'essaierai de le faire ce soir.
@+
--
JulienL
_________________________________________________________________
Windows Live Spaces : créez votre blog à votre image !
http://www.windowslive.fr/spaces
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
