Gontran Baerts a écrit :
- dans mon fichier « kde » j'ai « ftp://ftp.kde.org/pub/kde/stable »
- un autre utilisateur a « ftp://ftp.lip6.fr/pub/X11/kde/stable »
C'est mal. un autre utilisateur RAJOUTE des lignes à son fichier
mirroirs (au début ou a la fin, selon ses convenances). Mais il ne
devrait pas supprimer de lignes.
Si je teste la disponibilité des archives sources pour les mirroirs que j'ai
configuré, c'est utile pour moi, mais pour l'autre utilisateur, non.
Je propose donc de tester toutes les URLs sauf celles utilisant le protocole
mirror://. D'ailleurs, si mirror:// est utilisé, c'est justement pour pouvoir
se rabattre sur d'autres serveurs au cas où les archives ne seraient pas
trouvées sur l'un d'eux. Le « pire cas » serait qu'aucun des sites mirroirs
ne disposent des archives :^)
Nasgaia devrait fournir des fichiers mirroirs "officiels", avec lesquels
on ferait les test (j'avais d'ailleurs réunit une fort belle liste de
SF_MIR, si tu la veux Gontran). Je rappelle que le but de nbuild-spider
est de fournir un outils aux mainteneurs qui soit capable de les avertir
en cas de probleme avec leur(s) paquet(s). Un utilisateur standard de
nasgaia se tamponne gentiment le coquillard avec nbuild-spider.
NPKG_PRJ_SRC_URL="ftp://url/new/sources-1.0.tgz ftp://url/old/sources-1.0.tgz";
Ainsi, lorsque la version 1.1 sort, le nbuild pour la 1.0 restera valable car
Ncooker essayera la première URL qui échouera, et passera alors à la seconde
qui elle sera valable.
Ca regle pas mal de problemes, mais j'avais deja vu un projet ou le gars
ne laissait en ligne que la toute derniere version... Et si c'est arrivé
une fois, ca peut arriver plus souvent...
J'en profite pour demander s'il vous paraît utile que la commande check ait
des options pour désactiver certains tests, soit à un niveau général, par
exemple ne pas tester le fichier desc, ou bien le fichier infos, etc ... soit
un niveau plus bas : ne pas tester la variable version, ne pas tester la
variable release, ne pas tester les erreurs de syntaxe, ne pas tester la
présence des fonctions dans le fichier build, etc.
Pour l'instant, si elle teste tout, qu'elle affiche les erreurs sans
s'arreter dès qu'elle en voit une, c'est parfait. Pour le moment, je ne
vois pas l'utilité d'une myriade de sous-check, à part bien sûr le check
de disponibilité en download. les autres check visent plutot a verifier
la conformité du nbuild lui même, alors que ce dernier vise a s'assurer
de la disponibilité des sources (ce qui n'engage pas forcément la
validité du nbuild, en cas, par exemple, de panne du serveur hostant les
sources)
