> Inutile de changer le md5sum, il est mis à jour automatiquement par > Ncooker :-) Ceci étant, se « contenter » de changer la version n'est pas le > meilleur moyen de garantir un paquet de qualité, même si dans la plupart des > cas ça peut fonctionner sans problème. Un minimum de vérifications s'impose.
Je suis tout à fait d'accord avec toi, Les principales erreurs des contributeurs occasionnels sont d'ailleurs le manque de tests d'un paquet et le manque de vérification de la liste des fichiers/ répertoires d'un paquet. Je vois très souvent des paquets avec des docs au mauvais endroit, des répertoires qui devraient être enlevés et qui ne le sont pas, des choses comme /usr/etc/toto.conf, et tout cela vient du fait d'un manque d'attention de la personne qui fait le paquet. De même lors des mises à jours d'un paquet beaucoup ne regarde pas assez les changements d'un paquet. Un paquet avec de bonnes options dans le ./configure , des dépendances bien choisies et vérifiés ainsi que la structure des repertoires/fichiers très propre est un gage de qualité. > Alors en fait, tu confonds le changelog de l'application et celui du > nbuild :-) En effet j'avais mal compris :/ > Du coup, je me rends que, pour la fonctionnalité que tu proposes (mots-clés > security-fix, bug-fix, ...), l'utilisateur peut se demander si ça se rapporte > à l'application ou au nbuild :-) A priori, rien ne permet de le savoir. > J'aurai tendance à dire que c'est en rapport avec l'application (et dans ce > cas, tu as entièrement raison, il faut bien lire le changelog de > l'application pour savoir quels mot-clés mettre), mais dans ce cas, faut-il > bien les placer dans le fichier changelog du nbuild ? Je n'en suis plus si > sûr :-) Des avis ? ... Hum, je l'aurais tout de même mis dans le changelog, mais pas forcement sur la même ligne : % 1.0-nga2 Gontran <[EMAIL PROTECTED]> 2008-07-08T10:14:00Z [bug-fix security-fix] -> update-type=[bug-fix security-fix] % 1.0-nga2 Gontran <[EMAIL PROTECTED]> 2008-07-08T10:14:00Z blablabla > Pour ma part, je suis absolument contre ! :-) Parce qu'il ne faut pas se > faire > d'illusion, si ce n'est pas obligatoire, ça ne sera jamais fait ! Qui plus > est, un « bon » paquet, destiné à être placé sur le CD ou sur un serveur > officiel de paquets Nasgaia, n'est pas quelque chose qui se fait en 5 minutes > (c'est du moins mon avis :-) ). je pensais plus aux premiers paquets de tests qui serviront à avoir une base de travail (par exemple pour lancer la création des paquets kde, gnome , xfce le plus rapidement possible. Mais c'est vrai que cela ne ferait pas gagner vraiment beaucoup de temps :) Mais bien sur , lors de la création du 1er iso , (même de test) tous les paquets devront être parfait et vraiment finis ! > Bien sûr, un nbuildeur isolé pourra toujours mettre > n'importe quoi dans le changelog pour passer la vérification, mais il ne sera > pas reconnu officiellement par le Projet. Ça restera une contribution. Je sais pas si vous connaissez le système pour gérer les contribution de paquet de archlinux "AUR" : le site : http://aur.archlinux.org j'ai fait un petit article là dessus : http://www.archlinuxfr.org/content/view/8/70/ Des utilisateurs post leurs paquets (nbuild) qui vont dans un zone "unsuported" . Les utilisateurs votes pour les meilleurs paquets, et des utilisateurs de confiances choisis par la communauté ou par les dev officiels construisent les paquets et deviennent donc ainsi accessibles à la communauté via un repo community. Les dev officiels de la distribution peuvent ensuite venir chercher de nouveaux paquets dans ce repo community qui peut être considéré comme fiable. Et > j'espère fortement que la future équipe de packaging va mettre en place une > série de tests afin de contrôler le plus scrupuleusement possible les paquets > destinés à être officiels :-) Oui je pense aussi que cela est indispensable. Un test de paquets vraiment complet est très important. Sous archlinux il y a namcap : https://xentac.net/svn/namcap/trunk/Namcap/ voilà la liste des tests réalisé : -------------------- Namcap rule list -------------------- depends : Checks dependencies semi-smartly. directoryname : Checks for standard directories. fileownership : Checks file ownership. gnomemenu : Verifies gnome menu items are in the right directory. perllocal : Verifies the absence of perllocal.pod. permissions : Checks file permissions. symlink : Checks that symlinks point to the right place urlpkg : Verifies url is included in a package file capsnamespkg : Verifies package name in package does not include upper ca se letters emptydir : Warns about empty directories in a package md5sums : Verifies md5sums are included in a PKGBUILD tags : Looks for Maintainer and CVS Id tags url : Verifies url is included in a PKGBUILD invalidstartdir : Looks for anything that's not $startdir/pkg or $startdir/s rc capsnames : Verifies package name does not include upper case letters carch : Verifies that no specific host type is used sfurl : Checks for proper sourceforge URLs badbackups : Checks for bad backup entries le projet debian : http://lintian.debian.org/ Donc, dès que Ncooker aura suffisamment avancé on pourra créer notre outil de vérification de paquet :)
