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 ---------------------------------------------------------------------
> - 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 ... > - 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 ?) > - 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/ ! 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) ? > - 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 ) > 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 ) > La dernière enfin permet d'afficher des infos utiles pour compiler le paquet, > comme les options utilisables avec ./configure par exemple. ça c'est vraiment super ! > 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 ) > Là où ça commence à devenir plus intéressant, c'est que _toutes_ ces > fonctions, sans exception, seraient OPTIONNELLES ! C'est-à-dire que pour > certains paquets, il ne serait pas nécessaire de fournir un fichier build > pour générer un paquet NBA :-) > Comment cela est-il possible ? Tout simplement en intégrant à Ncooker un > comportement par défaut, proche du fameux triplet de commandes « ./configure; > make; make install » qui permet de compiler une très grande majorité > d'applications. > L'idée est que pour chaque étape, Ncooker regarde si le fichier build > contient > une fonction associée. Si c'est le cas, il l'exécute, sinon, il utilise celle > fournit par défaut avec la commande build. Puis il passe à la suivante en > procédant de la même manière. Ce n'est pas trop simple ? enfin, faudra se méfier de cette facilité lol > - Application des patches : comme précédemment, Ncooker regarde si la > fonction > do_patches() existe et la lance le cas échéant. Sinon, il applique > automatiquement les patches trouvés dans le répertoire /patches du nbuild. > Plusieurs choses peuvent être mises en place ici. D'abord, on pourrait > classer > les patches dans une arborescence : > > patches/ > |_ x86/ > |_ x86_64/ > Je ne connais pas les différences de compilations entre le x86 et le x86_64 à part les flags gcc, mais c'est vrai que cela serait vraiment super si l'on pouvait simplement classer les patchs par arch et rajouter des patchs dans "x86_64" en cas de problèmes de compilations. >Qui plus est, je me souviens que quelqu'un avait déjà > émis le souhait de pouvoir savoir qu'elles sont les options de ./configure > utilisées par défaut dans les nbuilds. Je propose une solution pour répondre > aux deux problèmes en même temps : utiliser une variable NPKG_CONFIG_OPTIONS > dans le fichier « infos » du nbuild. Par exemple : > > NPKG_CONFIG_OPTIONS="--prefix=/usr --with-ssl" Vraiment super !! > $ Ncooker build --config-options "--without-ssl" paquet.nbuild > > La commande lancée par Ncooker serait alors : > > ./configure $NPKG_CONFIG_OPTIONS <options passées à --config-options> > soit : > ./configure --prefix=/usr --with-ssl --without-ssl Génial !! > > - do_ckeck() : le comportement par défaut de Ncooker est de faire un grep sur > le fichier Makefile pour recherche une entrée « check: » ou « test: ». S'il > en trouve une, il lance la commande « make » qui correspond (make check ou > make test). > > - do_preinstall() : le comportement par défaut de Ncooker ne fait rien. > > - do_install() : le comportement par défaut de Ncooker est de lancer la > commande « make DESTDIR=$INST_ROOT install ». Parfois, il faut utiliser une > autre variable que DESTDIR. Il faut voir s'il y a un moyen de la trouver > automatiquement. Sinon, il faudra écrire la fonction do_install() dans le > fichier build directement. Humm, c'est la partie la plus critique je pense. DESTDIR; prefix; ou parfois rien , c'est vraiment pas facile de faire quelque chose de fiable automatiquement, enfin de toute façon il est impératif de vérifier le Makefile ! > - do_help() : le comportement par défaut est d'exécuter ./configure --help > si ./configure existe, et/ou d'afficher le fichier README/INSTALL s'ils > existent. Bonne idée > > Voilà pour l'idée de base :-) > La création d'un paquet nbuild serait ainsi grandement facilitée : > * dans le meilleur cas, il n'y a pas de fichier build à écrire, seules les > variables NPKG_CONFIG_OPTIONS et NPKG_MAKE_OPTIONS doivent être définies dans > le fichier « infos » (c'est Geekitus qui va être content ;-) ) Moi j'aime bien tout faire tout faire tout seul, aller chercher les dépendances sur le site web, faire le md5sum , faire le ./configure avec les meilleurs options possible, vérifier la liste des fichiers installé sur le système pour voir si rien ne "cloche" etc .. je vais faire quoi maintenant .. snif snif ... > Cette solution présente aussi l'avantage de laisser la liberté au nbuildeur > d'écrire l'ensemble des fonctions du fichier build s'il le souhaite, > indépendamment du fait que le comportement par défaut de Ncooker puisse ou > non convenir pour son paquet. c'est bien de laisser ce choix, pour certains paquets cela reste indispensable (comme le paquet kernel je pense) 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 ?
