Le 30/08/07, Julien L.<[EMAIL PROTECTED]> a écrit : > > Normallement, Ncooker génère une liste de dépendances de librairies en > utilisant ldd puis filtre cette liste en ne prenant que les libraries qui ne > sont pas déjà fournies par le paquet. C'est cette liste filtrée qui se > retrouve dans le fichier fulldeps. > > Par conséquent, je pense que le problème vient plutôt de la génération > automatique des dépendances. > > Est-ce que j'ai bien compris le problème ?
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 ? 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 ? -- Richard 'riri' GILL jabber: [EMAIL PROTECTED] http://riri.houbathecat.info http://nasgaia.org « Frimousse en excessivité émousse son expressivité » _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
