Petite réponse du dimanche, après on va faire un tour en campagne avec Houbi :-)
Le 30/04/06, Julien L.<[EMAIL PROTECTED]> a écrit :
>On peut partir sur cette idée, mais dans le même gabarit que pour la >génération d'un nbuild minimal, ce sera bien que Ncooker assiste le >nbuildeur dans la création de ces fichiers. Comme ça avait été >proposé, Ncooker pourrait générer les dépendances telles qu'il les >voit (je parle en particulier du basicdeps) avec des bons coups de >ldd. Bien-sûr, ce ne serait pas complet, et même trop exhaustif d'un >certain point de vue, mais ça 'macherait' le travail. Hummm. Je sais que c'est ce que vous avez tous proposé lors du précédent débat. Cependant, comme je l'ai déjà expliqué de façon informelle à certains des membres, il y a un truc qui cloche dans ce raisonnement. En effet, pour pouvoir faire un ldd sur un binaire, il faut déjà que ce binaire existe. Or, si un nbuildeur est en train de créer un paquet, c'est que ce binaire n'est pas encore installé sur son système... Le Nbuilder est donc contraint de déterminer les dépendances "a priori". Il devra utiliser la documentation du projet (fichiers "README", "INSTALL"), le site web du projet, la page freshmeat du projet et... sa connaissance. ;) Bon, maintenant, si le nbuildeur souhaite complèter le fichier "basicdeps", il aura toujours la possibilité de générer une première fois le paquet NBA, de consulter le fichier "fulldeps" généré et de modifier le paquet Nbuild en conséquence.
Ok
>on peut penser aussi à un mécanisme permettant de retrouver les >binaires à partir du PATH, plutôt que ce spécifier 'bin'. La plupart >des paquets à base des autotools permettent de spécifier un --bin-path >- ou équivalent -, et certains logiciels ne se placent pas toujours au >même endroit (même si les chemins relatifs bin/, lib/, etc.. sont >majoritaires) En fait, je n'ai pas encore décidé comment détecter si un fichier est présent sur le système. Je me disais qu'une façon de dire qu'un fichier est un binaire à trouver dans le PATH est... de le préfixer par "bin/" justement.
Ok
Je ne suis pas sûr que la recherche dans le PATH soit une bonne solution. Il peut arriver que l'utilisateur qui installe le paquet NBA (root) n'ai pas le même PATH que l'utilisateur qui va utiliser le paquet. Dans ce cas, la dépendance ne pourra pas être résolue lors de l'installation du paquet NBA. En fait, je crois qu'il n'y a pas de solution miracle mais que la solution la plus égalitaire soit de rechercher le chemin du fichier dans la base de données Ncooker, quelque soit le type du fichier.
La bonne solution serait des variables de recherche pour Ncooker, qui pourraient être basées sur les variables existantes d'ailleurs. Par exemple, un nbuilder qui crée un paquet n'a pas les sbin dans son path. La variable de Ncooker pourrait combler ce manque.
>>lib/libpango-1.0.so.0 (pango >= 1.3.2) > >Même idée que pour les binaires, un moyen de spécifier les répertoires >de bibliothèques en cherchant dans LD_LIBRARY_PATH Heu... Il me semble que la variable d'environnement LD_LIBRARY_PATH ne donne que la liste des répertoires complémentaire et pas toute la liste complète des répertoires. Est-ce que je me trompe ?
Pareil, variable propre à Ncooker, mais qui s'appuie sur LD_LIBRARY_PATH, qui ne contient tu as raison, que les répertoires supplémentaires aux recherches définies lors de la compilation de binutils (/lib et /usr/lib par défaut).
>Hmmm, je pense qu'il faudrait éviter au maximum les chemins absolus, >dans ce cas, share/lib/background.jpeg serait plus judicieux. cela >utiliserait le même procédé que pour trouver les différents bin et >lib.
Je suis d'accord mais je pensais à des cas bien particuliers où l'emplacement d'un fichier dépendant est fixé et non paramétrable. Pour bien comprendre, je vais essayer de prendre un exemple (qui est peut-être un peu bidon). Prenons le cas du paquet mplayer. Admettons qu'il existe un paquet mplayer pour le lecteur MPlayer et un paquer mplayer-basicplugins pour les plug-ins communs. Pour que le lecteur mplayer soit utilisable, il faut qu'il existe des plug-ins sur le système, dans le répertoire "/usr/share/lib/codecs/" (répertoire fixe et non paramétrable). Par conséquent, le paquet mplayer dépend du paquet mplayer-basicplugins. Comment indiquer cette dépendance dans le paquet mplayer ? On pourra ajouter dans le fichier "basicdeps" : /usr/share/lib/codecs/xvid.1.so
Doans le cas où le chemin ne peut *vraiment pas* être modifié oui, dans tous les autres cas, non. Par exemple, je ne suis pas sûr qu'on ne puisse: * d'une part modifier le chemin lors de la compilation (ou juste installation) des codecs * d'autre part définir le chemin de recherche pour mplayer Ce que je veux dire, c'est que dès qu'il y a possibilité de modifier un chemin (soit côté paquet qui définit le chemin, soit côté paquet qui a une dépendance dessus), il ne faut pas de chemin absolu. Effectivement, si cela ne peut pas être modifié (exemple bidon, /etc/passwd), ok il faudra bien mettre le chemin absolu.
>J'y ai pensé vaguement moi aussi, mais je me rend compte de 2 choses: >1) il me semble plus judicieux de séparer en deux fichiers ce qui est >créé par le nbuilder (saisie) de ce qui est généré automatiquement >(travail de Ncooker). Dans cet esprit, mettre les dépendances (surtout >les fulldeps) dans le fichier info ne me plait pas trop. En fait, il faut savoir que, en l'état actuel des choses, le fichier "infos" est modifié par Ncooker pour y ajouter des informations calculées automatiquement (le nom du Nbuildeur, les sommes MD5, ... par exemple). Par conséquent, cet argument n'est pas vraiment valable.
Et bien pourquoi ne pas en profiter pour scinder les valeurs en deux fichiers. Le premier est ce que le nbuilder écrit, le deuxième ce que Ncooker écrit. Je me rappelle que déjà à l'époque de Ncooker2 (nga 1.0), la modification du fichier info (ou desc, je me rappelle plus) me génait. -- Richard 'riri' GILL jabber: [EMAIL PROTECTED] http://riri.houbathecat.info http://www.gnurou.org/Writing/SmartQuestionsFr _______________________________________________ Nasgaia-dev mailing list [email protected] https://mail.gna.org/listinfo/nasgaia-dev
