Le Dimanche 3 Avril 2005 22:12, rouge a écrit : > 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.
Comme le dit Leif, on ne peut pas contrôler les changements que fait l'utilisateur. S'il a envie de virer toutes les urls de mirroirs fournies par défaut, et en mettre d'autres, c'est parfaitement son droit. Je ne suis pas pour l'en empêcher. > 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 veux bien ta liste de mirroir pour SourceForge :^) > > 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... Je pense que, quoi qu'il en soit, on ne pourra pas prévenir "tous" les problèmes. Le but de la commande Check est de signaler un maximum d'erreurs, d'étourderies, que peut commettre le nbuilder. Ça contribue à fournir des paquets de qualité, mais en aucun cas des paquets « parfaits » :^) nbuild-spider est un bon complément à « Ncooker check » > > 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) Ok, je suis d'accord avec la distinction que tu fais. Juste une précision : actuellement, la commande check arrête son traitement à la première erreur et retourne le code d'erreur associé. Elle n'est pas invoquée uniquement sur la ligne de commande par l'utilisateur, mais également par d'autres commandes en « interne », comme Pack, et le sera certainement par les futures commandes comme Install. Pour Pack, par exemple, Je considère que si Check retourne une erreur, ce n'est pas la peine de créer le nbuild, car il ne sera pas valide. Je pourrais modifier le comportement de Check pour qu'il affiche toutes les erreurs, mais normalement chaque erreur retourne un code différent. Là, seul le code de la dernière erreur serait retourné. Ce n'est pas obligatoirement génant car la commande Pack teste simplement si le code d'erreur est différent de 0, et ne réalise pas un traitement spécifique à chaque erreur de Check. Mais pour d'autres commandes, ce comportement pourrait ne pas convenir. A la rigueur, on pourrait modifier Check pour qu'il affiche toutes les erreurs par défaut. Comme ça, lorsqu'il est invoqué sur la ligne de commande, l'utilisateur aura la liste de toutes les erreurs d'un coup. Puis on ajoute une option à Check, qui serait utilisée par les commandes qui l'invoquent, pour qu'il s'arrête à la première erreur. Par exemple, Pack ferait : « check --stop-on-error ». AInsi dès que Check rencontre une erreur, il arrête son traitement et retourne son code. vos avis ? Gontran
