Le Vendredi 8 Juillet 2005 11:08, geekitus a écrit : > je pense aussi que le fichier changelog est l'endroit le plus adapté à > cette information. De plus ta méthode me convient parfaitement :) > > J'ai juste une petite remarque : utiliser changelog aussi complet > nécessite plus de temps au mainteneur. En effet en générale la mise à > jour d'un paquet ce résume à changer la version du paquet et le > md5sum -> donc 1 minute + le temps de compile.
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. > Ici cela nécessite d'aller sur le site internet du paquet, chercher > où est le changelog , lire quelques lignes pour comprendre la raison > de l'update. Cela doit prendre 5 à 6 minutes par paquet + la > compile. Alors en fait, tu confonds le changelog de l'application et celui du nbuild :-) Le fichier changelog intégré au nbuild n'a pas pour but d'indiquer les changements de l'application à laquelle il se rapporte, mais les changements apportés au nbuild « lui-même » ! Ce n'est pas notre rôle de rechercher les changements au niveau de l'application, c'est celui de ses auteurs. D'ailleurs, un fichier changelog est généralement fourni avec les sources de l'application et est intégré au NBA pour être installé dans /usr/share/doc/<nom de l'appli>. L'utilisateur peut donc connaître les différences s'il le souhaite. Si on regarde le changelog d'un paquet RPM comme subversion, on peut y lire : * lun jun 06 2005 Helio Chissini de Castro <[EMAIL PROTECTED]> 1.2.0-6mdk - Fix build - Removed invalid patches - Removed reconstruction of auto*tools * lun jun 06 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.2.0-5mdk - fix deps * jeu jun 02 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.2.0-4mdk - rename the apache sub packages (apache2/apache) - the conf.d directory is renamed to modules.d - use new rpm-4.4.x pre,post magic * lun mai 30 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.2.0-3mdk - added the ruby bindings on request by Andre Nathan - build it against neon 0.25 * ven mai 27 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.2.0-2mdk - fix deps again... * jeu mai 26 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.2.0-1mdk - 1.2.0 - fix deps - make the tests work. works on x86_64 too, nice. * sam mai 21 2005 Oden Eriksson <[EMAIL PROTECTED]> 1.1.4-2mdk - added P4 from fedora (x86_64 fixes) - disable running the tests on x86_64 for now, many tests fails - fix deps - rework the --with[out] magic On voit bien que ce sont des informations sur le nbuild lui-même, sur les modifications qui sont apportés pour corriger ses dépendances, les patches qui sont appliqués, modifier les paramètres de compilation ... Rien à voir donc avec les nouveautés de SVN. D'ailleurs, on peut voir que lors du changement de version de SVN de la 1.1.4 à la 1.2.0 (les deux dernières entrées), seule est indiqué « - 1.2.0 » dans le changelog pour montrer qu'on a changé de version, mais il n'y a aucune indication sur les nouveautés apportées. 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 ? ... > Cette nouvelle fonctionnalité est vraiment très intéressante mais > demande d'avantage de temps pour réaliser un paquet. > > Je pense que c'est une bonne chose de la coder tout de suite, mais > de façon non bloquante. Il faudrait pouvoir ou non utiliser cette > fonction sans pour autant générer d'erreur. Ainsi la première > série de paquets pourrait ne pas utiliser cette fonctionnalité (pour > facilité la création d'un maximum de paquets en un minimum de temps) , > puis par la suite lorsque nous aurons les paquets de base et les plus > utilisés (et que nous serons aussi plus nombreux) nous pourrons mettre > en place ce système. 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 :-) ). Il faut qu'il soit vérifié, testé, corrigé ... Les utilisateurs apprécieront d'avoir des paquets peaufinés, « travaillés », et cela ne pourra que renforcer l'image de la distribution en terme de qualité. 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. 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 :-) ++ Gontran
