• [^] # Re: rpm5

    Posté par (site web personnel) . En réponse à la dépêche Mandriva 2011. Évalué à 6.

    Le nettoyage de rpm 4.6 ne vient pas vraiment de Per Oyvind, plus des gens de Suse et de Red Hat ( notament celui que tu cites plus bas dans le commentaire ). Per Oyvind a porté des patchs en partie écrit par d'autres de Mandriva ( pixel, etc ) sur rpm5, et a rajouté ses idées à lui sans les annoncer ( exemple, les histoire de distEpoch, les histoires de %exclude etc ), entrainant des problèmes sur le système de build ( parce que oups, si on rajoute des tags, faut rajouter ça sur la miroir qui génère les indexes , et visiblement, personne n'a pu lui dire avant l'upload de rpm5, vu qu'il a fait les trucs dans son coin pour éviter les discussions et ce qui a entrainé des soucis bloquant tout le monde fin 2010 ) et des discussions houleuses ( qui ont poussés notamment le mainteneur de samba et de ldap à quitter le projet Mandriva, parmi tant d'autres https://www.mageia.org/pipermail/mageia-dev/20110303/002891.html ).

    Et contrairement à ce que tu dit, il y a des gens externes à Red hat qui contribue à rpm.
    Au moins un patch de Mandriva a été poussé sur rpm comme tu le fait remarquer ( par un volontaire de Mageia de surcroit ), c'est donc bien la preuve que c'est faisable ( exemple : http://lists.rpm.org/pipermail/rpm-maint/2011-March/002995.html ).

    Et du coté de rpm.org, on retrouve aussi des patches de gens de la communauté Fedora ( comme Vile Skytta ), ou des gens payés par Suse ( comme Michael Schroeder ). Il faut reconnaitre que c'est pas un travail que grand monde est prêt à faire sur son temps libre si la condition est de ne pas casser la compatibilité avec les vielles versions, comme maintenir la glibc. Et si j'en croit un dev rpm5 sur lwn, c'est pas vraiment la préoccupation de l'équipe rpm5 ( cf http://lwn.net/Articles/441282/ : "the reunification of version compare with dpkg" , chose qui va sans doute caser divers specs à gauche à droite, un peu comme le changement non discuté sur la sémantique de %exclude ).

    L'équipe est ouverte à la discussion, j'ai croisé Florian Festi ( dev rpm ), je l'ai vu discuter avec Olivier Thauvin ( ex commiteur rpm5 ) pendant une soirée entière, donc on ne peut pas dire ( ce que Per Oyind fait réguliérement, malgré d'une part un reality check : http://lists.mandriva.com/cooker/2011-05/msg00019.php et malgré les faits comme les liens que j'ai posté ici )

    Et non, il n'y a pas eu vraiment de duplication du travail par Mageia, vu qu'il s'agit de base de code différentes. Se dire que les projets font la même chose aprés 3/4 ans est une simplification. Soit il n'y a eu aucun changement majeur, et dans ce cas, pourquoi est ce qu'on dit que rpm5 est une avancée si le code est exactement le même, et pourquoi le BS de Mandriva a explosé si il n'y a pas eu de changements significatifs/
    Ou alors il y a eu des changements, et dans ce cas, c'est pas de la duplication, comme n'importe quel personne ayant un peu d’expérience en dev te le diras.

    Pour les histoires de lenteurs, il suffit de 2 seconde de recherche sur un moteur comme google pour trouver ça :
    http://lists.mandriva.com/cooker/2011-01/msg00093.php .

    Enfin, si tu parles d'avoir le code poussé upstream chez rpm5, c'est pas sans causer des soucis entre les 2 devs actifs :
    http://www.mail-archive.com/rpm-devel@rpm5.org/msg04893.html
    D'ailleurs, le code est poussé assez souvent entre des #ifdef, ce qui induit des comportement différent de rpm entre les distributions,, donc on repassera pour la partie "contribuer upstream". Si chaque distribution à une version différente du code compilé, ça reste toujours la même panade et l'unification n'est qu'illusoire pour faire croire au non codeur que du travail propre est fait. C'est du même niveau que les specs multi distribution de Jpackage.

    Les patchs de Suse sont aussi poussés chez rpm.org, donc je ne voit pas ou est ce qu'il y a une nouveauté ( exemple :
    http://lists.rpm.org/pipermail/rpm-maint/2011-May/003022.html , http://lists.rpm.org/pipermail/rpm-maint/2011-May/003010.html .