Bonsoir, j'ai bien envie que Nasgaïa avence ... Ncooker avec. Et je pense qu'il serait temps de se pencher sur une gestion des dépendances et tenter d'en implémenter une ... ca ne devrait pas être trop compliqué, si ?
VOila, j'ai vraiment envie de voir ça arriver alors je tente une petite réflexion... Alors, quels types de dépendances peut on avoir sur un programme ? 1- les bibliothèques dynamiques, on trouve facilement avec ldd 2- les fichiers de ressources 3- les bibliothèques dynamiques qu'on ouvre avec dlopen (c'est un peu comme un fichier ressource en fait) 4- les bibliothèques des langages de script (comme 2 et 3) Pour le 1, c'est facile, on prend ldd et on cherche le paquet qui fournit la bibliothèque dans un dossier listé dans $LD_LIBRARY_PATH. Ca doit être facilement faisable si on a la liste des fichiers fournis par les différents paquets. Pour le reste, ca devient plus compliqué et je ne pense pas qu'on puisse fournir un outil qui trouve tout seul ce qu'il faut ... sauf peut être pour certains langages de script (grep 'import' *.py). A mon avis, il faut garder la possibilité de faire des plugins permetant de découvrir des dépendances ... mais le mainteneur du paquet doit aussi vérifier que toutes les dépendances sont bien présentes. et doit pouvoir en ajouter si besoin est. Après, quel type de dépendances peut on avoir ? 1- une dépendance sur des fichiers 2- une dépendance sur des noms de ressources 3- une dépendance sur des noms de paquets + versions Pour le 1, une objection est qu'il faudrait avoir la liste de TOUS les fichiers fournis par TOUS les paquets pour pouvoir gérer les dépendances ... et que cela risque d'être lourd a gérer ... personellement, même si une telle liste est longue, un grep est toujours assez rapide (ce n'est pas un peu le principe de locate en fait ?) De toute façon, je pense que cette liste doit exister car l'utilisateur doit pouvoir rechercher un paquet en fonction du fichier qu'il installe ... Si la solution 1 est adoptée, il je pense qu'il serait intéressant d'avoir un endroit dans l'arborescence ou on aurait des fichiers servant a gérer les dépendances... pour permettre les meta-paquets notament. Chaque paquet pourait ainsi créer un fichier dans /var/lib/Ncooker/deps/<nompaquet> ... et ainsi un meta-paquet pourrait faire référance a d'autres paquets par ce fichier spécial. Si gérer ainsi la liste de tous les fichiers est un peu lourd, il est peut être possible de restreindre les fichiers a seulement des noms significatifs. Chaque paquet exporterait des noms qui pourraient correspondre a des noms de fichiers significatifs du paquet (nom d'une bibliothèque, d'un binaire, d'un dossier de ressource) ... et dépendrait d'autres ressources. L'avantage serait que la liste des éléments de dépendance serait plus légère. Cela permettrait éventuellement plus de flexibilité (exporter lib/malib.so au lieu de /usr/lib/malib.so ou /lib/malib.so). L'inconvénient c'est que lemainteneur du paquet peut avoir plus a intervenir pour exporter les bonnes chaînes. Il est toujours possible d'exporter automatiquement tous les fichiers se trouvant dans des répertoires clefs (exporter tout ce qu'il y a dans bin, lib et les dossier de share (sans leur arborescence)) Pour la 3e solution, les dépendances sur les noms de paquets, personellement, je n'aime pas trop car toute la flexibilité disparaît. J'ai un peu de mal a m'exprimer mais si on a un paquet (sun-jdk) proposant /usr/bin/java et qu'on veut rajouter un autre paquet (gcj) qui proposerait au hasard le même fichier /usr/bin/java. Avec des dépendances par fichiers on voit tout de suite que : - les deux paquets sont incompatibles car ils proposent les même fichiers - un paquet ayant besoin de /usr/bin/java dépend d'un de ces paquets. Avec des dépendancessur les noms de paquets, il faudrait explicitement dire dans le paquet sun-jdk qu'il est incompatible avec gcj ... et dans gcj qu'il est incompatible avec sun-jdk ... et il faudrait mettre a jour tous les paquets dépendant de java pour spécifier qu'ils peuvent aussi bien utiliser gcj ... Enfin voila ce que je pense ... ce ne sont que des idées, n'oubliez pas Mildred -- Mildred <xmpp:[EMAIL PROTECTED]> <http://mildred632.free.fr/> Clef GPG : <hkp://pgp.mit.edu> ou <http://mildred632.free.fr/gpg_key> Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B] _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
