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.
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. 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.
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.
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.
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.
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
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 . 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 ?
