Le 08/10/07, Julien L.<[EMAIL PROTECTED]> a écrit : > > > Je veux pouvoir au choix: > > a) ne pas avoir de dépendances (fulldeps vide) > > b) enlever des dépendances trouvées par Ncooker > > c) gérer moi-même les dépendances du paquet (cela ressemble à du > > 'human deps', mais s'en n'est pas tout à fait) > > Pour l'instant, le seul besoin concret est a). Pour le besoin c), il y a le > fichier basicdeps. Le besoin b) n'est pas encore d'actualité. Donc, je me > demande si il faut vraiment le prendre en compte.
b) j'ai le cas pour la glibc :) > > On a déjà éliminé 2), 3) et 4) ne permettent pas le b), qui est selon > > moi, le plus intéressant des cas. Il ne reste donc que 1) :-) > > > > Par ailleurs, pour rentrer dans le chipotage :p, je n'aime pas la 3) > > car lle introduit une option à une focntion interne, chose dont on > > peut se passer. > > > > Reste (si la solution 1) est retenue) à trouver un nom pour une > > fonction de génération des fichiers de paquet à appeler avant > > npkg_create_nba(), pour chaque paquet. Si seul le fichier fulldeps est > > traité de la sorte, c'est facile, mais on est parti pour permettre la > > surcharge de n'importe quelle action entre la création du fakeroot et > > celle du nba. Je propose juste comme ça : pkg_gen_pre_nba() - je ne > > trouve pas le nom terrible pour tout vous avouer, mais je n'ai pas > > trouvé mieux :-) > > Si on ne trouve pas de nom, c'est que la solution retenue n'est pas claire. ;) ce n'est pas faux :) > Pour ma part, je proposerais une cinquième solution (un compromis entre la > solution 2 et la solution 4 en fait) : > - des fonctions permettent de générer les fichiers fulldeps, product et files > (une fonction par fichier) > - la fonction npkg_create_nba vérifie si chaque fichier existe, et s'il > n'existe pas, appelle la fonction correspondante. > - le comportement par défaut de la fonction do_prepackage est nul > - si un nbuildeur veut contrôler le contenu d'un des fichiers (fulldeps, par > exemple), il définit la fonction do_prepackage en appelant la fonction > correspondante (la fonction de génération du fichier fulldeps, par exemple) > puis en appliquant des modifications au fichier généré (suppression d'une > dépendance, par exemple) > > Cette solution me paraît souple et évolutive. Qu'en pensez-vous ? Bon je crois que je vais laisser tomber :) Mais ta solution, si elle permet certaines choses, n'est pas aussi souple que ce que je propose, et plus compliquée aussi, puisque je proposais d'avoir la génération par défaut, mais de pouvoir retoucher derrière (soit en supprimant, soit en altérant soit en ajoutant). Sans avoir d'exemple concret à donner (à part ma terrible glibc qui s'intègre très ien dans ta solution par ailleurs), j'essaye de penser Ncooker le plus ouvert possible sur les besoins spéciaux des utilisateurs, car c'est l'une de mes grandes frustrations avec tous les gestionnaires de dépendances que je connais (soit on n'a rien, soit on est forcé de tout faire passer par ce gestionnaire, alors qu'il suffit de peu de chose). -- 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
