Le Samedi 9 Juillet 2005 02:52, Leif Thande a écrit :
> Quelques petits commentaires en vrac :
>
> 1 -------- Extraction des paquets -------
>
> Concernant le dépaquetage automatique des archives sources, est-ce que
> l'ancien Ncooker possédait une commande pour le faire ?
> Une simple
> détection de l'extension permettrait de dépaqueter l'archive avec une
> commande du genre "unpack l'archive". Cette commande pourrait être
> externe à Ncooker, elle pourrait s'avérer intéressante pour les
> fainéants. De plus, Ncooker pourrait vérifier si l'archive contient
> les sources dans un dossier ou directement l'arborescence :
>
> Ex;
>
> foo-1.0.tar.gz ---> foo-
> \-src
> -README
>
> foo-2.0.tar.gz --> -src
> -README
>
> Ce détail est important pourqu'on puisse se placer dans le bon dossier
> pour compiler. Je sais que dans l'ancienne version on devait spécifier
> une variable dans le fichier info, automatiser cela pourrait être
> intéressant. Bien sur, les cas particuliers pourraient toujours être
> fait à la main.
Le Ncooker actuel traite les archives d'une manière un peu particulière :
lorsqu'il les télécharge, il les convertit au format tar.bz2 pour réduire la
place occupée sur le disque. Lorsqu'il fait ça, il regarde si la variable
CREATE_DIR existe, elle contient alors le nom du répertoire obtenu lors de la
décompression de l'archive. On est alors dans le cas d'un développeur
rigoureux qui a compressé son répertoire contenant les sources, et pas
directement les fichiers sources eux-mêmes. Si c'est la variable REPACK_IN
qui est définie, cela signifie que l'archive contient directement les
fichiers sources (sans répertoire), et il faut les ré-archiver dans un
répertoire nommé $REPACK_IN lors de la conversion de l'archive au
format .tar.bz2.
Ce système oblige le nbuildeur à vérifier le contenu de l'archive source pour
savoir s'il doit déclarer la variable CREATE_DIR ou REPACK_IN dans le fichier
infos. Pour la version de dév de Ncooker, j'ai créé un module nommé
« uncompress » qui gère automatiqument la décompression des archives sources
en fonction de leur extension. Il regarde aussi la structure de l'archive
pour savoir si on obtient un unique répertoire avec tous les fichiers
sources, ou bien les fichiers sources directement. Dans ce dernier cas, il
place automatiquement les fichiers dans un répertoire portant le nom du
paquet.
Ça n'a pas encore été testé et il y a sûrement des bugs ou des cas non-prévu,
mais en tout cas, le principe est là :-)
> 2 ------ Valeur par défaut des sections do_* ----
>
> Je ne suis pas convaincu que ce soit une bonne idée. Premièrement
> parce que cela ammène des risques d'erreurs.
Lesquels ?
> Bien sur, c'est au
> mainteneur de s'assurer que son paquet fonctionne.
> Deuxièment, Ncooker
> étant sujet à changement, il faudrait que absolument que les fonctions
> par défaut demeure "backward compatible" , faute de quoi une bonne
> partie des anciens paquets deviennent inutilisables.
Il faudra de toute façon sortir plusieurs versions bêta de la version de dèv
de Ncooker pour bien tester toutes les fonctionnalités et être sûr qu'elles
répondent aux besoins des nbuildeurs et des utilisateurs. Le but étant de
fournir un gestionnaire de paquets le plus idéal possible pour éviter d'avoir
à apporter de grosses modifications qui casseraient la compatibilité. Malgré
ça, Ncooker continuera à évoluer même après la sortie de la prochaine version
stable, et qui sait, il faudra peut-être modifier le format des paquets pour
adopter des nouveautés technologiques intéressantes. On ne peut pas le
savoir ...
Cependant, la version de dév de Ncooker possède un nouvel atout non
négligeable : sa modularité. Si nous somme amenés à devoir changer
radicalement le format des paquets par la suite, nous pourrons développer un
nouveau module pour gérer ce nouveau format, tout en gardant le module qui
gère le format actuel en parallèle. Ncooker utilisera alors l'un ou l'autre,
en fonction de la version avec laquelle a été fait un paquet. Ce qui m'amène
à penser qu'il faut indiquer la version de Ncooker qqpart dans les
paquets :-) . Je propose de la mettre dans la balise racine <Npkg> :
<Npkg version="3.0">
> Troisièmement, il existe des paquets qui n'auront pas besoin de
> section do_make , par exemple des paquets ne faisant que copier de la
> documentation (lea_book) . Dans ce cas, toutes les sections ayant des
> options par défaut devront contenir "Echo 'Nothing to do here'" ou
> "/bin/true". À mon avis, c'est un peu contradictoire à la philosophie
> Unix qui est "Tu veux quelques chose, demande le ; Tu ne veux rien,
> ferme ta gu.... ". Et puis les risques d'oublie sont encore plus
> importants ici.
Les fonctions par défaut ne consistent pas à lancer « bêtement » les commandes
habituelles ./configure, make et make install :-) Il est évident qu'un
minimum de vérification doit être fait. Par exemple, la fonction do_make()
par défaut pourrait ressembler à ceci :
do_make() {
if [ -f Makefile ] && grep -q "^all:" Makefile; then
make $NPKG_MAKE_OPTIONS
fi
}
La vérification consiste ici à, primo, vérifier qu'il existe bien un fichier
Makefile, et secundo, vérifier qu'il contient une entrée « all: ». C'est
uniquement lorsque ces conditions sont remplies que la commande make est
lancée.
Inutile donc d'ajouter des fonctions avec « echo "Nothing to do" » pour
« désactiver » le comportement par défaut.
> On pourrait utiliser une commande internet du genre use_defaults pour
> satisfaire les 2 cotés. Sinon, s'assurer que le fait que Ncooker
> utilise des fonctions par défaut si elles ne sont pas définie soit
> bien documenté pour éviter des maux de têtes aux nouveaux packagers.
Oui, j'avais pensé à la solution inverse qui consiste à placer dans le paquet
une instruction « disable-defaults » pour désactiver le comportement par
défaut de Ncooker. Mais si les fonctions par défaut sont bien « réfléchies »,
je ne pense pas que ce soit utile.
Sinon il est clair que le comportement par défaut devra être bien expliqué.
Mais j'ai l'intention de fournir un bon manuel utilisateur pour Ncooker ;-)
> 3 ------ Les subdivisions do_* ------
>
> Est-il vraiment nécessaire d'avoir autant de subdivisions ?
> Personnellement je m'y perd. Pour les fonctions par défaut je comprend
> que ce soit utile mais bon, j'émet mes réserves la dessus quand même,
> c'est à discuter.
Les subdivisions ont pour rôle essentiel de bien découper les différentes
étapes du processus de compilation et de génération du paquet NBA. Ceci
permet au buildeur de contrôler finement le déroulement de ce processus, car
Ncooker lui offre des fonctionnalités permettant de n'exécuter qu'une ou
plusieurs étapes données. Ceci est très pratique pour la mise au point d'un
nbuild. C'est vrai qu'il ne faut pas non plus tomber dans l'excès :-) Mais il
faut savoir que pour une application ne nécessitant aucun patch et aucune
modification, les seules fonctions à définir sont :
do_config()
do_make()
do_install()
do_package()
Ce n'est pas la mort ! :-)
>
>
> 4 ----- Les options de ./configure ------
>
> Permettre d'afficher et de modifier les options de ./configure,
> personnellement j'adore ! Seule chose, comme je l'ai déjà mentionné, à
> ce moment la les deps ne tiennent plus. Une solution : faire un
> MASS_COMPILATION . En gros, ce pourrait être une commande du genre
> Ncooker mass_build qui compilerait une version d'un programme pour
> chaque option différente offerte dans le ./configure. ldd se charge
> ensuite de donner les dépendances pour chaque paquet généré. Ces
> dépendances sont incluses dans le fichier depends du PKGBUILD.
>
> Désavantes évidents :
>
> 1- C'est long, très long.
> 2- Alourdissement considérable du nbuild. ( on se retrouve avec 10+
> fichiers depends )
> 3- Les dépendances humaines ne sont pas prises en compte.
> 4- C'est chaotique.
>
> Bref, je crois que l'on devrait se contenter de fournir les
> dépendances pour le paquet avec les options de compilation de base.
> Celui qui recompile s'assure lui-même d'avoir les dépendances
> d'installées
Oui, cette solution est théoriquement la mieux, mais très longue :-)
Ce serait bien de pouvoir indiquer des dépendances optionnelles dans le nbuild
en fonction des options du ./configure. Chacune d'elles serait ou non indiqué
dans les dépendances du NBA selon que l'option correspondante du ./configure
ait été utilisée ou non. À creuser ...
> 5 ---- Comportement par défaut pour strip, enlever les locales etc.. -----
>
> Les comportement par défaut de ces étapes pourraient être définies
> dans le fichier Ncooker.conf.
Oui
> la variable NPKG_LOCALES pourraient
> contenir les locales que l'on désire garder. Au fait , ne peut on pas
> spécifier les locales à compiler directement à configure ou make ?
À vérifier. Je ne sais pas s'il y a une méthode générale pour toutes les
applications.
++
Gontran
