Le Vendredi 8 Juillet 2005 20:00, geekitus a écrit : > je suis désolé pour toutes les bêtises que vous allez lire ... je > connais pas encore assez bien Ncooker pour pouvoir réellement > proposer de bonnes améliorations
T'inquiète pas, ton avis est toujours le bienvenu ! ;-) > --------------------------------------------------------------------- > > > - do_preconfig() : cette fonction est utilisée pour appliquer des patches > > aux fichiers sources et/ou à modifier des fichiers à l'aide sed ou awk > > par exemple. Plus généralement, elle permet de modifier certains > > paramètres avant que l'environnement de compilation soit généré. > > Pour facilité encore plus et uniformiser la syntaxe d'un Nbuild (car il > y a plusieurs façon de faire un sed..) des petites fonctions genre > do_sed ou do_awk prenant simplement par exemple do_sed toto tata > nom_fichier , enfin, je sais pas si c'est pas trop noeud noeud, mais > ça permet d'avoir la fonction do_preconfig encore plus simple et plus > lisible , nan ? De plus par exemple "do_mkdir /etc/toto ferait > automatiquement le dossier toto dans le répertoire "fakeroot" pour > éviter ainsi des erreurs (de même pour le "ln" etc ... Perso, je ne suis pas trop pour ce genre de fonctions. Pour moi, do_sed() ne serait qu'une « enveloppe » autour de sed et je ne vois pas vraiment ce que ça apporte si ce n'est éviter de devoir indiquer une ou deux options. À la rigueur, ce genre de fontions pourrait peut-être être utile dans la fonction do_postinstall() pour effectuer des manipulations dans le fakeroot ... mais la version actuelle de Ncooker définit une variable $INST_ROOT contenant le chemin d'accès au fakeroot, et c'est encore ce qui reste le plus simple et le plus ouvert pour le nbuildeur. Il peut utiliser les commandes qu'il veut pour manipuler ou modifier les fichiers qui s'y trouvent. J'ai peur que s'y on commence à fournir une fonction do_sed, il va falloir fournir une enveloppe pour plein d'autres commandes (ln, awk, mv, cp, rm, ...) et ça va obliger les nbuildeurs à devoir apprendre leur utilisation. > > - do_config() : cette fonction lance le script ./configure avec les > > options voulues, ce qui a pour effet de préparer l'environnement de > > compilation. > > peut on envisager un système de USE à la gentoo mais vraiment plus > minimaliser pour les quelques paquets qui en auraient vraiment > besoin ? (avec un maximum de 2 ou 3 paramètres pour laisser lisible > cette fonction ?) Ncooker utilise déjà des variables USE_* similaires au USE de Gentoo (Voir le manuel « Ncooker Cookbook » rédigé par votre serviteur :-) http://winuxien.free.fr/Manuel_NCooker_V.1.0-alpha1.txt). Je pense qu'il faudrait revoir ce système, mais chaque chose en son temps. Occupons-nous d'abord de la base du fichier build ;-) > > - do_preinstall() : cette fonction permet de préparer l'environnement > > pour installer l'application dans un fakeroot, un dossier utilisé comme > > s'il s'agissait de la racine de l'arborescence du système. Dans beaucoup > > de paquets actuels, elle est utilisée pour copier des fichiers > > d'informations (AUTHOR, README, NEWS, CHANGELOG ...) dans le fakeroot. > > Perso, je trouve que cela aurait plus sa place dans la fonction > > do_postinstall() (voir plus loin). > > question bête : l'utilisation de l'utilisateur root est interdite ou > pas pour la compilation d'un paquet ? (enfin quand je vois le nombre de > personnes qui font leurs paquets en root, et qui les font mal : > exemple : l'utilisation de --prefix=$fakeroot/toto alors que cette > variable prefix n'est pas présente dans le makefile.. donc au finale en > compilant leur paquet et croyant l'installer dans le fakeroot , le > paquet est directement installé sur le / et pas dans le $faketoot/ ! Les paquets peuvent être compilés au choix en root ou sous son propre compte utilisateur. Il est même possible d'avoir un fichier de configuration Ncooker personnel dans ~/.Ncooker/Ncooker.conf pour utiliser des paramètres différents de ceux définis dans le fichier de configuration global /etc/Ncooker/Ncooker.conf. > Peut on interdire de créer des répertoires dans un autre endroit que > le fakeroot ? (sauf en utilisant des fonctions do_mkdir etc.. comme > je l'ai proposé au dessus) ? Je ne sais pas si c'est possible, mais j'aimerais beaucoup mettre en place un système pour surveiller l'endroit où sont installés les fichiers. Pour moi, la solution que tu proposes n'est pas très fiable dans le sens où rien n'oblige un nbuildeur à utiliser tes fonctions. Il pourrait très bien utiliser les commandes de base du système pour placer volontairement un fichier quelque part à ton insu. Il faut que ce système de surveillance soit interne à Ncooker et indépendant de ce que fait l'utilisateur. Peut-être existe-t-il un programme permettant de surveiller les opérations effectuées par un autre processus sur les fichiers du système ? Si qqn connaît un programme de ce type, je suis preneur ... > > - do_install() : cette fonction procède à l'installation de l'application > > dans le fakeroot. Elle fait généralement appel à la commande « make > > DESTDIR=$INST_ROOT install » où la variable $INST_ROOT, positionnée par > > Ncooker, contient le chemin d'accès au fakeroot. > > Même question qu'au dessus : peut on interdire l'installation dans un > autre endroit que le fakeroot ? (ou Ncooker peut il vérifier que des > fichiers ne sont pas installés dans un autre endroit ? et dans ce cas > avertir du problème ) Même réponse qu'au-dessus ;-D > > > La première permet de réaliser soi-même la décompression des archives > > sources au lieu de laisser Ncooker le faire. Ça peut s'avérer utile avec > > certains paquets comme le driver Nvidia par exemple. > > Ine peut on pas aussi faire un utilitaire permettant de faciliter la > packaging des paquets proprio comme Nvidia (enfin, j'ai vu que plusieurs > distribs avaient fait un utilitaire ou un script pour ça .. je vais > regarder de plus près ) Je ne pense pas que ce soit utile. La version de dév de Ncooker devrait fournir tout ce qu'il faut pour traiter ces paquets un peu spéciaux. Mais tiens-moi au courant ... > > Les plus attentifs auront remarqués que j'ai ajouté un « s » à la > > fonction do_package() :-) car je souhaite ajouter la possibilité de > > générer plusieurs NBAs à partir d'un seul NBUILD :-) C'est un autre sujet > > ... > > je ne comprend pas bien je pense ... plusieurs paquets avec un - > configure différent ? enfin, d'un coté c'est peut être pas logique > d'avoir plusieurs paquets avec un seul nbuild nan ? (enfin pour une > utilisation perso oui, mais comment maintenir plusieurs paquets avec un > seul Nbuild ?) ou plutot comment faire la différence entre les nga > générés ? à moins que 1 seule version du nga soit dispo en > téléchergement ? (hum, là je pense que je suis en train de dire de > grosses grosses bétises lol; dsl ) Ok, je me suis mal exprimé :-) Certaines applications peuvent être séparées en plusieurs parties : les binaires, les librairies, les includes pour le développement, ... Mais tout cela est fourni dans la même archive source. L'idée est de séparer en plusieurs paquets NBA le résultat de la compilation pour que l'utilisateur final n'installe que ce qui lui est réellement utile. Prenons Ssh, par exemple ; après compilation, on obtient différentes choses : les exécutables pour le serveur ssh, et ceux pour les commandes « client ». À partir du NBUILD ssh ssh-4.1-nga1.nbuild, on pourrait obtenir deux NBAs ssh-server-4.1-nga1-i686.nba et ssh-clients-4.1-nga1-i686.nba, par exemple, qui contiendrait respectivement les binaires pour le serveur et les commandes clientes. Ainsi, l'utilisateur qui n'a besoin que des commandes clientes installerait uniquement ssh-clients-4.1-nga1-i686.nba sur son système. > Juste un proposition : peut on aussi envisager de facilité la création > de paquets cvs/svn avec un ou deux variables déjà prévu genre "cvsroot" > et "cvsmod" , une fonction viendrait télécharger cvsroot/cvsmod > automatiquement si les variables sont initialisés ? Si on veut des faire paquets qui utilisent la version de dév des applis, on peut prévoir de gérer des urls ayant comme protocole cvs://... et svn://... pour télécharger les fichiers sources à la place d'une archive source. Par exemple : NPKG_PRJ_SRC_URLS="cvs://[EMAIL PROTECTED]" ou <archive> <url>cvs://[EMAIL PROTECTED]</url> </archive> avec le nouveau format XML du fichier info (il faudrait utiliser un autre nom pour la balise <archive> parce que dans ce cas, ce n'est pas représentatif de ce qui est récupéré sur le serveur). Pour la version, on pourrait utiliser « cvs » pour le paquet nbuild et « cvs + date » pour le nba : toto-cvs-nga1.nbuild toto-cvs20050711-nga1-i686.nba ++ Gontran
