Sortie de rpm 5.0.0

Posté par  . Modéré par j.
Étiquettes :
0
17
jan.
2008
Technologie
La version 5.0.0 de RPM (RPM Packages Manager) vient de sortir.

Il s'agit de la première version majeure de la version rpm5.org de RPM, le gestionnaire de paquets permettant de gérer l'installation de logiciels sur quelques distributions GNU/Linux. Pour rappel, rpm5 est le fork initié par Jeff Johnson après son départ de RedHat. Le RedHat Packages Manager est lui disponible en version 4.4.2.2 sur le site rpm.org.

Parmi les changements notoires :
  • Nettoyage du code, y compris la partie autotools ;
  • Choix du format de la rpmdb : Berkeley DB et/ou SQLite ;
  • rpm5 a été porté sur de nouvelles architectures, y compris MacOS X ;
  • Concernant les formats de compression, à gzip et bzip2 déjà pris en compte, a été ajouté le support du format lzma ;
  • La liste des tags disponibles est désormais extensible : pour les distributions, le but est de pouvoir stocker des informations supplémentaire selon leurs besoins ;
  • Il est désormais possible de marquer des macros en lecture-seule.

À savoir aussi que :
  • Les fichiers de configuration 'rpmrc' (définition des architectures) ont été supprimés, au profit d'une configuration complète au travers de macros ;
  • Le format rpm v3 n'est plus supporté.
Ces deux derniers points font que rpm5 5.0.0 ne peut pas être utilisé pour remplacer une version 4 sans évaluation et adaptation. Mais la vraie question est désormais de savoir comment vont se comporter les différents forks face aux rpms générés par leurs homologues.

Aller plus loin

  • # R ?

    Posté par  (site Web personnel) . Évalué à 6.

    Le R de RPM : c'est bien Redhat ?
    Et si je comprends bien, rpm5 et "rpm" ne sont plus compatibles 100%.
    et "rpm" est toujours le système de packages officiel de redhat ...

    Par conséquent : encore une belle pagaille en perspective ;-)

    deb rulez ;-)
    • [^] # Re: R ?

      Posté par  . Évalué à 2.

      apt-get remove --purge rpm
    • [^] # Re: R ?

      Posté par  . Évalué à 2.

      Le R de RPM : c'est bien Redhat?

      Non , le R veut dire RPM. (C est la 1ere ligne de la news) :)
      Tout comme WINE, le W veut dire WINE
      Je crois bien qu' il y ait un nom a ca, mais je ne m'en souviens pas

      @++
      • [^] # Re: R ?

        Posté par  . Évalué à 5.

        Ce sont des acronymes récursifs.
      • [^] # Re: R ?

        Posté par  (site Web personnel) . Évalué à 2.

        Je crois bien qu' il y ait un nom a ca, mais je ne m'en souviens pas


        c'est un acronyme récursif
        • [^] # Re: R ?

          Posté par  (site Web personnel) . Évalué à 10.

          Histoire de chipoter il s'agit plutôt d'un sigle récursif. Un sigle est une suite d'initiales au d'abréviation. L'acronyme est un sigle que l'on prononce en le lisant comme un mot.

          Exemple :

          GNU se prononce « gnou », c'est donc un sigle et un acronyme,

          RPM se prononce « airpéhème », ce n'est donc qu'un sigle.

          Je crois que c'est avec le GNU que Richard Stallman a initié beaucoup de blagues pas très drôles et surtout un confusion systématique pour le geek qui s'est mis à appeler acronyme tout sigle lui passant sous le nez.

          J'ajouterai (parce que je suis gai comme un mormon) que je décourage fortement de faire des sigles juste parce qu'ils ont l'air sympa ou font un jeux de mot marrant en rapport avec ce qu'ils désignent. Non que ce ne soit pas bien : on en a juste trop.

          Bisous ! (on fait jamais assez de bisous)
        • [^] # Re: R ?

          Posté par  (site Web personnel) . Évalué à 1.

          C'est un acronyme récursif.
          • [^] # Re: R ?

            Posté par  (site Web personnel) . Évalué à 0.

            C'est un acronyme récursif.
            • [^] # Re: R ?

              Posté par  . Évalué à 0.

              C'est un acronyme récursif.
              • [^] # Re: R ?

                Posté par  (site Web personnel) . Évalué à 0.

                C'est un acronyme récursif.
                • [^] # Re: R ?

                  Posté par  . Évalué à -2.

                  C'est lourd.
                  • [^] # Re: R ?

                    Posté par  (site Web personnel) . Évalué à 2.

                    Surtout que je ne vois pas vraiment où se trouve la récursion là-dedans, juste une pauvre bouclé itérative.
                    • [^] # Re: R ?

                      Posté par  (site Web personnel) . Évalué à 8.

                      ça dépend :
                      - tu descend toute la chaine de commentaire pour la lire et la mémoriser
                      - arriver en bas tu te rend compte à quel point c'est lourd...
                      - tu remonte la chaine en te rappellant des tous les commentaire, et en les moinsant au passage
                      sa peut se programmer de manière récursive (et bien plus éllegament qu'en itératif si tu n'aime utiliser explicitement un tableau ou autre pour stocker tes contextes)

                      Le problème ici c'est que je déconseille d'utiliser la récursivitée pour le faire sur linuxfr, les trolls pouvant parfois être extrèmement long il y a un risque d'exploser la pile...
                      • [^] # Re: R ?

                        Posté par  (site Web personnel) . Évalué à 1.

                        Enfin, si tu fais ta récursivité dans un bon langage en la programmant bien (c'est à dire en utilisant la récursion terminale) tu n'a aucun risque d'exploser ta pile. Donc je conseille le récursif.
    • [^] # Re: R ?

      Posté par  (site Web personnel) . Évalué à 3.

      Oui, à l'origine le R est celui de Redhat puis ils l'ont transformé en acornyme recursif...

      Il est de même pour GCC...

      Parfois, on garde même l'acronyme même si l'institution change de nom complètement, cf le CERN.
      • [^] # Re: R ?

        Posté par  . Évalué à 7.

        Aux dernières nouvelles, GCC est toujours l'abbréviation de GNU Compiler Collection (à l'origine GNU C Compiler) et non pas un acronyme récursif GCC Compiler Collection.
  • # Les distributions?

    Posté par  . Évalué à 2.

    Quelle distribution utilise quoi? Je sais que chez Mandriva il était question de passer à la compression LZMA pour les RPM....

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Non évènement

    Posté par  (site Web personnel) . Évalué à 10.

    Cette branche de RPM ne sera vraisemblablement utilisé pas personne (du moins pas par des distros importantes).

    Pourquoi ? C'est la branche développée par Jeff Johnson et ce mec n'est visiblement pas fiable.
    Comme RPM stagnait et que Jeff Johnson refusait de corriger des bugs gravissimes dans le code les distros majeures ont décidé de s'allier et de reprendre la main sur le développement de RPM.

    Pour cela le site rpm.org a été créé ou le travail de maintenance a lieu....mais J. Johnson a lancé son site concurrent (rpm5.org) pour garder le contrôle du projet et essayer de tuer dans l'oeuf rpm.org.

    Les distros n'ont pas mordu à l'hameçon et cette sortie de RPM 5.0.0 est donc un non évènement.

    Il y a un commentaire ici ( http://lwn.net/Articles/263965/ ) dont je trouve qu'il résume bien la situation : "The last thing we need is to become dependent, again, upon a project headed up by a uncooperative developer. The XFree86->Xorg move has clearly been beneficial. Standardizing on the Jeff Johnson fork of RPM would be unwise, and a step backwards, in my opinion."

    Une autre personne a écrit : "Based on my previous interaction with Jeff Johnson, I think I'll be giving this a miss. I'll stick with distributions using a package manager written by someone I trust to get it right. And I'm afraid that's just not Jeff...

    Cette interaction désastreuse est visible ici : https://bugzilla.redhat.com/show_bug.cgi?id=119185
    On voit que Jeff Johnson a joué à la tête de con (il n'y a pas d'autre mot) pour éviter d'avoir a corriger un bug conduisant à une corruption de la base RPM.

    Un article de LWN résume bien les choses ( http://lwn.net/Articles/196523/ ) :
    "The ensuing conversation - lasting for over two years - deserves to become a textbook example in how not to respond to bug reports. (...) Mr. Johnson repeatedly closed the bug, stating his refusal to fix it. Numerous other participants in the discussion made it clear that they disagreed with this "resolution" of the bug, but nothing, it seemed, could convince the RPM maintainer to put in a fix."

    C'est ce genre de chose qui a forcé Red Hat, Fedora, OpenSuse a s'allier pour faire sortir RPM de sa stagnation : http://lwn.net/Articles/214255/

    Conclusion : Comme avec XFree, je pense que cette branche RPM va tomber dans l'oubli.
    • [^] # Re: Non évènement

      Posté par  . Évalué à 3.

      Pour être honnête, Jeff Johnson a continué après son départ à maintenir RPM, mais quasiment aucune distribution n'a osé toucher à sa branche. jbj n'a pas été viré pour avoir refusé de corriger des bogues "gravissimes" mais pour son comportement cavalier avec les utilisateurs uniquement à propos du bug #11985 (et uniquement celui-ci). Ironie de l'histoire, il finira par corriger ce bug dans son fork (RPM 4.4.5).
      Greg De Koenigsberg résume très bien la situation.

      When we fired jbj, we didn't have the courage to draw a line in the sand and say "we're taking upstream ownership of RPM back." Why not? Because we thought it would be difficult politically? Because we didn't want the responsibility anymore? Because nobody in management actually cared enough to think about the ramifications? I don't know.

      Fast forward a year plus, and here we are. We're in a position where we have, essentially, forked RPM -- and no one is willing to admit it. No one is willing to take ownership of what we've done.

      Perhaps jbj "owns" RPM, in its current incarnation, by default, because no one else is willing to touch it. That's fine. He can have it. But that is not what *we* are using.


      La vérité est qu'aujourd'hui RPM5 est plus avancé, il a fallu près d'un an à Paul Nasrat (mainteneur actuel) et à Panu Matilain pour prendre en main le code et le nettoyer, ça fait pas très longtemps que RPM a commencé à aller de l'avant.
      Néanmoins, la période de "flottement" a prouvé que sans le soutien de RedHat , tout fork de RPM a peu de chances de survivre. Novell, MandrivaSoft (malgré un soutien affiché à RPM5) auraient pu récupérer la branche de jbj ou reprendre les choses en main, mais on attendu la réponse de RedHat.
      De plus, la direction du fork ne plaisait pas spécialement à RedHat.

      http://www.redhatmagazine.com/2007/02/08/the-story-of-rpm/
    • [^] # Re: Non évènement

      Posté par  . Évalué à 5.

      Tes remarques indiquent que manifestement tu n'est pas au fait de beaucoup de choses.

      C'est Jeff Johnson qui est parti de chez RedHat, la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer. D'ailleurs le RPM de rpm.org n'aura plus de changements majeur et gardera un grand nombre de lacunes. (AMHA)

      Quand à la LSB, c'est un troll stérile. La LSB stipule qu'il faut utiliser le format RPM v3. Ce format était déjà obsolète au moment de l'écriture de la LSB ! Les débianneux apprécient aussi surement ce standard qui exclue de fait leur distribution (et ubuntu, et slackware, et gentoo, etc...)

      Enfin parler d'une sortie de stagnation de la part de RedHat et OpenSuse c'est peu dire, il leur a fallu 2 ans pour se positionner et se remettre à toucher à leur RPM après le fork de Jeff Johnson. Et en plus ils ne sont pas parti de rpm 4.4.8 qui était le dernier dans le CVS encore commun, mais de rpm 4.4.2.

      Pour le reste, le rpm générés par rpm5 sont compatibles avec rpm 4.x.
      • [^] # Re: Non évènement

        Posté par  (site Web personnel) . Évalué à 3.

        >>> Tes remarques indiquent que manifestement tu n'est pas au fait de beaucoup de choses.

        Je suis toujours ravi d'apprendre des trucs.

        >>> C'est Jeff Johnson qui est parti de chez RedHat, la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer.

        Donc après son départ de Red Hat il est devenu le mainteneur upstream et il pouvait faire ce qu'il voulait...hors il a continué a refuser de corriger des problèmes (cf plus haut).

        >>> Quand à la LSB, c'est un troll stérile.

        Nulle part dans mon post je n'évoque la LSB. En parler est donc de ta part effectivement un troll stérile.

        >>> il leur a fallu 2 ans pour se positionner et se remettre à toucher à leur RPM après le fork de Jeff Johnson

        L'annonce de la reprise en main de RPM par les distros date du 14 décembre 2006 : http://lwn.net/Articles/214255/
        Soit il y a un an et un mois (et pas deux ans).
        Les premiers mois ont été consacrés (comme c'est normal lors d'une reprise) à s'approprier et nettoyer le code.
        Ensuite, dès le 23 juillet (soit 7 mois après la reprise en main), la sortie de la version 4.4.2.1 : https://lists.dulug.duke.edu/pipermail/rpm-announce/2007-Jul(...)
        Ensuite le 3 octobre la sortie de la 4.4.2.2 : https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-Octobe(...)

        Tu peux voir que le changelog est assez conséquent. Ta phrase est donc tout simplement fausse.
        • [^] # Re: Non évènement

          Posté par  . Évalué à 4.

          Donc après son départ de Red Hat il est devenu le mainteneur upstream et il pouvait faire ce qu'il voulait...hors il a continué a refuser de corriger des problèmes (cf plus haut).


          Et il l'a fait: rpm 4.4.4, 4.4.6, 4.4.8. Toutes ces versions ont existées avant que RedHat ne se bouge.

          Nulle part dans mon post je n'évoque la LSB. En parler est donc de ta part effectivement un troll stérile.


          L'article auquel tu fais référence en parle.

          Soit il y a un an et un mois (et pas deux ans).


          Je parle du délais entre l'annonce du départ de Jeff Johnson et donc d'un fork à venir au moment où RedHt à annoncé la mise en place du nouveau rpm.org.

          Donc gosso modo du délai entre rpm 4.4.2 et 4.4.8.
          • [^] # Re: Non évènement

            Posté par  . Évalué à -2.

            > Et il l'a fait: rpm 4.4.4, 4.4.6, 4.4.8. Toutes ces versions ont existées avant que RedHat ne se bouge.

            Red Hat a bougé. Fedora est resté à la version 4.4.2. Idem pour SuSE.
            Ces trucs sont très compliqué à gérer. Rpm est largement utilisé, Red Hat n'allait pas fermer http://www.rpm.org/ et l'accès au CVS de Johnson du jour au lendemain. Il y a eu une transition. Mauvaise car il y avait conflit (ou suspicion)

            Enfin, c'est gentil de critiquer Red Hat pour son manque de dynamisme, mais c'est le seul qui a repris les choses en main. Mandriva a rien foutu ni même donné un soutient (d'ailleurs Mandriva est passé à rpm 4.4.8 pour revenir à la branche Red Hat/Fedora).

            Qu'au sein de Red Hat on critique la mollesse de Red Hat au début de cette affaire, je comprend très bien. Mais que les autres critiques alors qu'ils n'ont rien fait, je ne comprend pas.


            En passant, Jeff Johnson est un excellent développeur qui a fait un excellent travail pour rpm.
      • [^] # Re: Non évènement

        Posté par  (site Web personnel) . Évalué à -5.


        C'est Jeff Johnson qui est parti de chez RedHat

        Mwahahaa ! Le problème Jeff Johnson est connu depuis avant son licenciement.
        Je ne comprends pas bien l'intérêt qu'il y a à le défendre. Groupie Mandriva ?
        • [^] # Re: Non évènement

          Posté par  . Évalué à 3.

          Moi je ne comprends pas pourquoi dans cette histoire les gens considère RedHat comme exemplaire.

          Pour ma part, j'ai appris l'existence du "fork" de RedHat sur un des listes de rpm.
          Ce mail nous expliquait que le cvs avait été migré sous mercurial et qu'ils cherchaient à regrouper les gens. En gros tout était fait.
          Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.

          Enfin pour ce qu'il s'est passé entre Jeff Johnson et RedHat, je ne pense pas que grand monde ait une vision claire.

          Quand à Mandriva, je ne vois pas le rapport avec la choucroute.
          • [^] # Re: Non évènement

            Posté par  (site Web personnel) . Évalué à 3.

            >>> Enfin pour ce qu'il s'est passé entre Jeff Johnson et RedHat, je ne pense pas que grand monde ait une vision claire.

            C'est clair qu'il nous manque peut-être des infos....mais la lecture des échanges sur le bugzilla montre bien la personnalité de JJ.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 2.

              Un point de vue depuis l'autre coté, ça aide toujours à équilibrer les choses:
              http://trainofthoughts.org/blog/2008/01/06/rpm5-vs-rpm/
              • [^] # Re: Non évènement

                Posté par  . Évalué à 1.

                Ralf S. Engelschall fourni l'hébergement de rpm5.org.

                Je ne sais pas trop de quel autre coté tu parles, mais donc il faut juste savoir ça.
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 1.

                  > Je ne sais pas trop de quel autre coté tu parles

                  Il serait un peu bête de cherche un bon et mauvais côté.
                  Il y a eu désaccord entre Johnson et Red Hat.
                  Johnson n'a pas tenu de propos "orduriers" envers Red Hat et vice versa. Il n'y a pas eu de "sabotage", etc.
                  Red Hat a laissé le cvs de rpm.org à disposition de Johnson, ainsi que les mailings. Ceci afin qu'il continu son boulot avec ceux qui partage ses objectifs. Notons que même si Red Hat en avait le droit aux yeux de la lois, il ne pouvait pas décemment se le permettre.

                  Johnson n'a pas réclamé de "propriété" pour le nom RPM. Johnson ne prétent pas être LE rpm. En passant, rpm n'est pas une marque protégé, et on voit la confusion que ça crée. Pas de quoi en faire un formage dans ce cas.
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 3.

                  L'autre coté, c'est lire le compte rendu de la même histoire mais d'après le point de vue de quelqu'un qui travaillait avec jbb pour pouvoir pondérer le total, pour répondre à patrick_g qui disait:
                  C'est clair qu'il nous manque peut-être des infos
                  On avait déjà 2 points de vue, celui des partisans de red hat qui ne voient aucune responsabilité de red hat dans cette affaire, tout est la faute à jbb, et celui des utilisateurs qui soit blamaient jbb, soit blamaient red hat.
                  Maintenant, on a le 3ème qui dit: jbb est un codeur génial, il ne pouvait pas faire évoluer le soft comme il voulait donc chez redhat et donc on lui a fait porter la responsabilité de ce genre d'affaires à tort, il est heureux d'avoir quitté red hat et depuis, il fait enfin évoluer son soft et du coup, ce fameux bug a pu être fixé.
                  • [^] # Re: Non évènement

                    Posté par  (site Web personnel) . Évalué à 3.

                    Il faut lire aussi ce qu'il (Engelshall) dit à propos du fameux bug: l'attitude de jbb ne lui semble pas anormale, particulière certes, mais compréhensible.

                    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Non évènement

            Posté par  . Évalué à 5.

            > Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils
            > allaient reprendre leur version, se sont déroulées sur les listes RedHat ou
            > Fedora. Sûrement un signe d'ouverture.

            Même pas toutes les discussions préliminaires se sont faites en interne Red Hat avec consultation discrète des autres distributions utilisant rpm.

            Ce qui était parfaitement normal.

            Il aurait été suicidaire pour Red Hat de faire une annonce publique sur le sujet avant :
            A. d'avoir recruté des développeurs capables de reprendre la base de code
            B. de s'être assuré que les autres distributions majeures utilisant rpm étaient prêtes à se joindre à l'aventure
            C. d'avoir planifié la logistique pour remettre rpm.org en ordre de marche rapidement.

            Un gestionnaire de paquets est le cœur d'une distribution Linux moderne. La moindre incertitude publique sur le devenir de rpm aurait été extrêmement dommageable pour toutes les distributions basées sur rpm. Et on pouvait compter sur jbj pour attiser la polémique (ce qu'il s'est empressé de faire avec rpm5.org)
            • [^] # Re: Non évènement

              Posté par  . Évalué à 1.

              > Même pas toutes les discussions préliminaires se sont faites en interne Red Hat

              Tu parles de quoi ?
              Oui Red Hat a eu des discussions en interne. Pour embaucher un développeur (mettre du "cash"), tu ne vas pas en discuter avec d'autres. Pour voir s'il est "rentable" de mettre un développeur ou deux sur rpm au-lieu de bidule, tu ne vas pas en dicuter avec les autres.

              > avec consultation discrète des autres distributions utilisant rpm.

              Il y a toujours des contacts "privés". Mais la consultation a été annoncée très tôt et de façon public. Et en gros on peut affirmer qu'elle a été quasiment ignorée (il n'y a que SuSE qui a donné son soutient à Red Hat pour relancer rpm.org).

              Je pense que les messages "privés" ont dû être hypra limité si jamais ils ont existé.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 3.

              > Un gestionnaire de paquets est le cœur d'une distribution Linux moderne.

              Non, non et non.
              Si je passe d'Ubuntu à Mandriva je change de coeur ?
              Je ne crois pas. Il y a des distributions rpm qui utilisent synaptic par défaut et l'ancien utilisateur de deb ne se rend même pas compte qu'il est passé à rpm avant d'avoir gratté un peu le verni.

              C'est un élément très très important pour certains utilisateurs (développeurs, etc).

              Mais ce n'est pas plus le coeur que Linux (le noyau), la libc, X11, un système de fichier, etc...
              • [^] # Re: Non évènement

                Posté par  . Évalué à 5.

                Oui, oui et oui.

                Tu peux changer la version majeure du noyau, de la libc, de X11, etc et toutes les distributions le font régulièrement.

                Aucune distribution sérieuse ne va s'amuser à changer de gestionnaire de paquet comme ça. C'est trop impactant. Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer. Même quand plusieurs distributions utilisent le même gestionnaire de paquets le jeu fonctionnel utilisé diffère généralement. Et de nombreuses distributions ont été fondées autour d'un choix de gestionnaire de paquets qu'elles doivent ensuite gérer pendant des années.

                Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 1.

                  > Aucune distribution sérieuse ne va s'amuser à changer de gestionnaire de paquet comme ça.

                  Ou changer de compilateur, etc...

                  > C'est trop impactant.

                  Comme le changement du compilateur. Le compilateur serait le "coeur" de l'OS ?
                  On ne devrait plus dire GNU/Linux mais GCC/Linux ?

                  > Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer.

                  Ça dépend des distributions.

                  Donc selon toi Xandros == Debian ?
                  CentOS == Mandriva ?

                  > Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.

                  Pareil pour gcc.
                  • [^] # Re: Non évènement

                    Posté par  . Évalué à 4.

                    Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.

                    Avec ton niveau d'argumentaire vache == cheval (après tout c'est des mamifères à quatre pattes qui mangent de l'herbe).

                    C'est bien de prendre de la hauteur mais à trop forcer on finit par ne plus rien distinguer.
                    • [^] # Re: Non évènement

                      Posté par  . Évalué à 2.

                      > Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.

                      Je ne vois où tu veux en venir a part conclure que le gestionnaire de paquet n'es tpas le coeur d'une distribution.

                      > Avec ton niveau d'argumentaire vache == cheval

                      Tu changes bien le coeur des OS seulement avec un gestionnaire de paquet.
                      Une vache à quatre pattes, comme un cheval.
                      Ça bouffe comme un cheval, ça a un regard attendrissant, et désolé, ça peut aussi se manger. Bref, plein de point en commun. Et au niveau ADN on doit avoir dans les 95 % d'ADN commun.

                      Mais tu veux faire de l'oreille de la vache son coeur (dans le sens "centre", "essence" et pas organe). Partant de la et constatant que l'oreille de la vache est différente de l'oreille du cheval, tu conclus qu'une vache et un cheval ça n'a rien à voir. Les anes et les chevaux n'ont pas les même oreilles.



                      Je te laisse à ton fétichime du gestionnaire de paquet.
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 1.

                  Et joubliais un "petit truc".
                  Tu peux installer des rpm sur Debian/Slack/etc. Et les programmes marcheront.
                  Pour l'utilisateur que ça soit "apt install" ou "yum install" ne change pratiquement rien. On trouve des programmes qui interfacent deb et rpm. Si PackageKit devient populaire, sûr que beaucoup d'utilisateurs ne sauront plus quel gestionnaire ils utilisent.
                  Les gestionnaires de paquet sont une "commodité". Certes importante pour des développeurs/admins, mais c'est tout. Ce n'est pas le coeur de l'OS. Loins loins de la.
                  Que dirais-tu si Windows passe à Deb ? Que Windows a changé de coeur ? Que Windows == Debian ?

                  Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.

                  Beaucoup de gens veulent conserver une barrière (artificielle) entre les distributions selon le gestionnaire de paquet. D'autant plus quand c'est pour surfer sur le "rpm puxor" et "donc" que l'autre distribution est nulle.

                  Tout ça c'est de la merde.

                  Le cas où ça commence à devenir vaguement pertinant, c'est pour les distributions orientés sources vs distribution "normal".
                  • [^] # Re: Non évènement

                    Posté par  (site Web personnel) . Évalué à 1.

                    Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.


                    Mon choix pour ArchLinux s'est fait par rapport entre autre à Fedora car je cherchais un OS avec un système de paquets facile a utiliser (comprendre, facile a créer et installer des paquets).
                    Sinon, Fedora, je trouvais bien. Tout ou presque fonctionne par défaut, pas besoin de configurer à la main ... du bonheur quoi. Sauf quand il fallait installer un logiciel tiers.
          • [^] # Re: Non évènement

            Posté par  . Évalué à 1.

            > Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.

            En passant, toutes les mailing Fedora sont ouvertes.
            Avant le départ de Johnson le problème a été posé.

            Red Hat n'a peut-être pas été exemplaire, mais que dire des autres ?
            C'est marrant cette façon de critiquer Red Hat alors qu'en même temps on attend tout de Red Hat. Les gens n'attendent rien de SuSE (pourtant ils utilisent rpm), rien de Mandriva (pourtant ils utilisent rpm), etc...

            > Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.

            Et alors ?
            Red Hat devait s'inviter sur les mailling Debian pour discuter de rpm ? Pour discuter s'il fallait débloquer des fonds pour embaucher ? Pour évaluer en quoi rpm est critique pour le business de Red Hat ?
            C'est ridicule.
          • [^] # Re: Non évènement

            Posté par  . Évalué à -1.

            Quand à Mandriva, je ne vois pas le rapport avec la choucroute.


            Ben si! Mandriva va utiliser rpm5 pour débuter l'unification des distros linux basées sur rpm en partenariat avec Turbolinux!!

            Poussez pas toute façon je cours vite!! ----> [ ]
      • [^] # Re: Non évènement

        Posté par  . Évalué à 2.

        > la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer.

        Que non. Il proposait des évolutions que ne voulais pas son employer. Notons que SuSE a très tôt indiqué que la direction de Johnson ne leur plaisait pas et qu'il resterait, comme Fedora, à la version 4.4.2. Mandriva a fait comme d'hab : ignoré Red Hat/Fedora "officiellement".

        Chez Red Hat, il suffit de regarder Fedora, il y a une grand latitude pour l'initiative des développeurs (du moment que les questions prioritaires sont réglées : sécurité, support, etc).
        Il n'a pas écouté son employeur, il a été viré. Ou on lui a indiqué avec insistance la direction de la porte. Si j'ai bonne mémoire, lors des 8 derniers mois de Jeff Johnson chez Red Hat, il y avait un fork pour Fedora (d'où Fedora qui est resté à la version 4.4.2 et une grosse pile de patch).

        > C'est Jeff Johnson qui est parti de chez RedHat

        Il n'est pas parti, on l'a viré. Les choses n'ont peut-être pas été aussi "violente". M'enfin, tu le dis, tout ce qui a fait après 4.4.2 a été pris avec des pincettes.

        > D'ailleurs le RPM de rpm.org n'aura plus de changements majeur

        Que tu dis.
        Et quel changement majeur tu veux ? Que rpm passe à deb ?
        Soit plus spécifique.

        > et gardera un grand nombre de lacunes. (AMHA)

        Quelles lacunes ?
        Qu'un truc ne soit pas parfait, ça toujours comme ça.
        Compare avec deb (et non apt), et rpm est sans problème aussi bon (voir aussi rpmbuild).

        > Les débianneux apprécient aussi surement ce standard qui exclue de fait leur distribution (et ubuntu, et slackware, et gentoo, etc...)

        Pourquoi ? C'est un format. Prend le format deb, et t'as le même problème.
        Il fallait un format. Il fallait faire un choix, "trancher".
        Lsb est surtout pour les ISV (Independent software vendor). Et dans ce domaine l'histoire montre que choisir rpm au-lieu de deb est "normal". Je ne dirais pas que c'était incontournable. M'enfin, deb apporte quoi de plus ? À part le tag "suggestion" ?

        > Et en plus ils ne sont pas parti de rpm 4.4.8 qui était le dernier dans le CVS encore commun, mais de rpm 4.4.2.

        Beaucoup d'éléments des version post 4.4.2 sont dans la 4.4.2.


        L'un des problèmes de rpm, est qu'il roxe. Oui, oui. Oublions tout le FUD, rpm roxe. Il fait son taff et on l'oublie. Trouver des développeurs pour rpm alors que rpm fait l'affaire est "compliqué".
        • [^] # Re: Non évènement

          Posté par  . Évalué à 3.

          L'un des problèmes de rpm, est qu'il roxe. Oui, oui. Oublions tout le FUD, rpm roxe. Il fait son taff et on l'oublie. Trouver des développeurs pour rpm alors que rpm fait l'affaire est "compliqué".


          C'est comme perl quoi.
        • [^] # Re: Non évènement

          Posté par  . Évalué à 3.

          perso je sais pas ce que deb apporte par rapport à rpm, mais une chose est sur , si apt c'est top cool par rapport à yum.
          sous fedora ou sous centos ou mandriva, les updates, ajouter ou retirer un paquet , etc... c'est LENT!

          alors, est ce que RPM5 (pas le format, l'ensemble des outils;)) est aussi rapide qu'aptitude ?
          (c'est une vrai question)
          • [^] # Re: Non évènement

            Posté par  . Évalué à 0.

            > les updates, ajouter ou retirer un paquet , etc... c'est LENT!

            C'est lent comment ?

            J'ai fait un test avec un machine virtuelle (installe mini-mini, kvm en full-virtualisation, périphérique loopback).
            [root@rslnvirt ~]# time yum install openoffice.org-draw openoffice.org-math openoffice.org-langpack-fr openoffice.org-calc openoffice.org-impress openoffice.org-graphicfilter openoffice.org-writer
            [...]
            Transaction Summary
            =============================================================================
            Install 137 Package(s)
            Update 0 Package(s)
            Remove 0 Package(s)

            Total download size: 184 M
            [...]
            real 1m58.744s
            user 0m28.640s
            sys 0m15.213s

            Moins de 2 minute pour 184 Mo compacté.


            [root@rslnvirt ~]# time yum remove glib2
            [...]
            Transaction Summary
            =============================================================================
            Install 0 Package(s)
            Update 0 Package(s)
            Remove 90 Package(s)
            [...]
            real 0m26.932s
            user 0m8.586s
            sys 0m4.740s


            Il y a peut-être plus rapide, mais plus rapide je m'en fous.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 2.

              Je pense qu'il faisait plutot allusion à ça :


              # time yum -C search mutt
              [...]
              real 0m14.672s
              user 0m10.161s
              sys 0m2.584s
              #


              14 secondes, je trouve que c'est long pour une recherche locale. Surtout que sur une debian qui est moins puissante que la machine où la redhat (5.1) est installée :


              $ time apt-cache search mutt
              [...]
              real 0m2.404s
              user 0m1.256s
              sys 0m0.236s
              $


              Et la debian me sorte nettement plus de packages (35 différents contre 2 fois le même packages pour la redhat).
              • [^] # Re: Non évènement

                Posté par  . Évalué à 1.

                Sur la Fedora 8 du boulot:

                $ time yum search mutt
                [...]
                real 0m1.822s
                user 0m1.546s
                sys 0m0.216s
                $ yum --version
                3.2.8
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 1.

                  Tant mieux alors, sur la RHEL 5.1, yum est en version 3.0.1. Ca devrait être bon pour la prochaine redhat alors.

                  Merci

                  Etienne
              • [^] # Re: Non évènement

                Posté par  . Évalué à 5.

                Perso, pour moi simple utilisateur, c'est la recherche qui me bloque le plus. Yum search est affreux par défaut, très lent, et indiquant des paquets plusieurs fois s'ils sont dans plusieurs dépôts. En plus, je n'ai pas compris comment faire pour n'afficher que le nom des paquets et non pas toute la description.

                Je ne suis pas qualifié pour dire si la lenteur est dû à rpm ou yum. Cependant, il est clair qu'un urpmq -y est largement plus rapide et plus efficace, même si pas aussi rapide que apt-cache.
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 4.

                  > En plus, je n'ai pas compris comment faire pour n'afficher que le nom des paquets et non pas toute la description.

                  Fait "yum install yum-utils".
                  il y a repoquery dedans :
                  [test@one ~]$ repoquery --all | wc -l
                  11531
                  [test@one ~]$ repoquery --all | grep mutt
                  mutt-5:1.5.17-2.fc8.x86_64
                  [test@one ~]$ time repoquery --all --queryformat="%{NAME} %{ARCH} %{LICENSE}\n" | grep -i mutt
                  mutt x86_64 GPLv2+ and Public Domain

                  real 0m3.999s
                  user 0m3.766s
                  sys 0m0.247s
                  [test@one ~]$ repoquery --querytags | wc
                  28


                  4 secondes pour 11500 paquets, ça va.

                  On peut faire des choses plus exotiques :
                  repoquery --provides java-1.7.0-icedtea | xargs repoquery --whatrequires --queryformat="%{NAME}\n" | sort | uniq
                  avalon-logkit
                  axis
                  azureus
                  bolzplatz2006
                  castor
                  checkstyle
                  classpathx-mail
                  dtdparser
                  freecol
                  graphviz-java
                  ...


                  Pour confort tu peux te faire des alias.
              • [^] # Re: Non évènement

                Posté par  . Évalué à 0.

                Putain, la vache! 14sec!!
                C'est vrai quoi, si à l'heure actuelle, on est pas capable de descendre sous les dix secondes pour chercher un soft alors qu'on court cent mètres en moins de dix secondes, où va-t-on!
                ...
                Vous êtes ridicules de parler de 'long' en parlant de 14 sec. Ça dépend de tellement de choses:
                installation (desktop, server,...)
                occupation du disque
                cpu
                mem
                ....
                Ridicule

                J'ai pas trouvé d'autre synonyme, et j'ai pas 14 sec à perdre à ce genre de foutaise.
                Faudrait pas oublier que Linux est multitâches, c'était son principal atout à l'époque, dans les années '90. Alors pendant que rpm cherche ton soft, regarde un divx, ça t'aidera à prendre patience.

                La patience est la reine des vertus.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 1.

              > Moins de 2 minute pour 184 Mo compacté.

              df avant/après :
              [root@rslnvirt ~]# df . ; df -i .
              Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
              /dev/sda1 3960316 823212 2932680 22% /
              Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
              /dev/sda1 1022976 26725 996251 3% /
              [root@rslnvirt ~]# df . ; df -i .
              Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
              /dev/sda1 3960316 1347248 2408644 36% /
              Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
              /dev/sda1 1022976 47104 975872 5% /


              Plus de 500 Mo installé, soit plus de 4,3 Mo/s.
              Plus de 20 000 fichiers/répertoires, soit 170 fichiers/s.

              En passant, les paquets sont downloadés depuis un réseau local et non depuis internet.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 2.

              c'est lent du style plusieurs minutes.

              Visiblement c'est quand il construisait un index.
              J'avoue que j'ai pas beaucoup regardé.

              Une grosse update c'est(était) lent aussi. Alors peut être que la façon de recupérer les fichiers d'index ne conviennent pas autant que pour debian, mais bon je trouvais ça vraiment lent (purement subjectif donc) (maintenant la machine est sous debian XD).

              Pour finir sur les "mauvais point avec le gestionnaire de paquetage" :
              lors de l'installation ... fc8 ne sait PAS faire de netinstall.

              J'ai tout essayé, incapable de me faire une netinstall sur un serveur http public....
              Et il faut aller chercher le miroir que l'on veut, et noter le path sur un papier pour l 'installer.

              Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\

              J'ai installé une debian, il me demande quel mirroir je veux dans une liste, et fait tout comme un grand.
              Il me demande aussi si je veux mettre à jour quand je fais une install "standard", et me re-propose la liste des miroirs.

              Bref, niveau netinstall debian 1, fedora 0 pour moi.
              • [^] # Re: Non évènement

                Posté par  . Évalué à 2.

                > fc8 ne sait PAS faire de netinstall.

                C'est f8 en passant.
                Et f8 c'est faire une installation via réseau (je l'ai fait).
                Fedora fait ça depuis le FC1 !
                Mieux, tu peux aussi faire une installation réseau via vnc.
                Il y en a qui installe Fedora, graphiquement, sur dédibox.
                Tu peux le faire avec Debian ?

                > Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\

                Admettons.
                Tu peux installer via bootp (noyau et initrd récupéré sur le réseau).

                Je veux bien admettre que ça manque de polish.
                Mais ça marche puis des années ! Depuis RH 6.2 au moins (j'ai fait des netinstall avec RH 6.2).

                > Il me demande aussi si je veux mettre à jour quand je fais une install "standard"

                Tu peux faire l'installation et la mise à jour en même temps sous Fedora. Dans ce cas Fedora ne va pas installer toto v1 (de la release) puis mettre à jour vers toto v2 (des mises à jours). Il installe directement toto v2.
                Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
                Il suffit à l'installation d'ajout un dépôt avec les mises à jours.

                Alors pas d'accord pour dire que Fedora ne fait pas de netinstall. Fedora (et Red Hat) le fait depuis des lustres. Par contre, je suis tout à fait d'accord pour dire que ça manque de polish et qu'il faut lire un peu de doc (donc ce n'est pas accessible pour un newbi qui ne veut pas se prendre la tête).
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 0.

                  Et f8 c'est faire une installation via réseau (je l'ai fait).
                  Ben tu es un surhomme alors.

                  Parce que j'ai essayais toute une journée, changé les miroirs itou ... a jamais voulu marcher.
                  Le mieux que j'ai pu avoir c'est commencer l'install, mais lors de la liste des packages il trouvait jamais rien /o\ (hors si il commençait l'install, il allait chercher l'installateur sur le réseau, vu que j'ai essayé avec une image netinstall puis, voyant que ça ne marchait pas, un cd)

                  ... miroirs que je devais noter sur un bout de papier , le path aussi . Qu'est ce qu'on se marre \o/

                  Fedora fait ça depuis le FC1 !
                  Assez mal il faut croire..

                  Ps : tous les miroirs que je testent sont sur internet, pas sur un intranet.

                  Tu peux le faire avec Debian ?
                  Aucune idée, tant que faire une netinstall simple avec FC8 n'est pas dispo, savoir qu'on peut faire le café avec fc8 ne m'intéresse guère.


                  Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
                  Il suffit à l'installation d'ajout un dépôt avec les mises à jours.

                  "J'aime bien le "il suffit".
                  Regarde comment fait debian, tu verras que c'est BEAUCOUP plus intuitif.

                  Déja : tu n'as RIEN a noter! avec les risques d'erreur que ca comporte (le path je le prend en absolu ? je dois taper l'arch et la version ou pas ? ...)
                  Deuxio : pour la maj il te le propose, ce n'est pas a toi de penser de rajouter un dépôt etc...


                  Alors ca peut te paraitre con, mais désolé, ce sont des choses qui sont vraiment agréables quand tu teste une nouvelle distrib : tu ne dois pas penser à tout, et si tu la teste, c'est que par definition, tu ne connais pas tous les "trucs"...
                  • [^] # Re: Non évènement

                    Posté par  . Évalué à 1.

                    dans le cadre de mon travail nous faisons de l'installation réseau avec fedora

                    actuellement en fedora core 6.


                    fedora hérite de redhat , tout naturellement.

                    on indique un "kickstart" (on le stock sur un serveur http ou nfs) via dhcp à l'installateur redhat/fedora

                    l'installateur peut être donné à l'ordinateur via un cdrom, bootp ou autre

                    le kickstart va indiquer à l'installateur où chercher ses paquets et quoi mettre , les paquets seront simplement disponible sur un mirroir de cd redhat/fedora en http (ou autre, nfs, voir smb je pense maintenant est possible)


                    bref, y a de nombreuses possibilités , le plus simple étant un cdrom avec un boot personnalisé (isolinux.cfg) pour aller chercher un kickstart sur un serveur web avec un les rpm sur un serveur web.


                    --
                    notons que le kickstart cherché peut dépendre du nom de la machine (donné par dhcp), peut être généré par php avec des paramètres etc. on peut imaginer beaucoup de possibilité.

                    -
                    notons aussi que toute install de redhat/fedora génère un fichier kickstart (dans /root) résumant la configuration et qu'il faut juste avoir la copie d'un cd d'install sur un serveur web pour disposer d'un netinstall fonctionnel

                    on prend le cdrom d'install habituel, on boot la machine, on indique d'installer par réseau, on lui donne l'adresse http et zou. c'est très facile ce niveau là, suffit d'avoir copier son cd/dvd dans un site web accessible.

                    si on ne donne pas d'indication où trouver un fichier kickstart, il faudra configurer à la main l'installation, les paquets seront pris depuis l'adresse indiquée.

                    -
                    dhcp permet d'indiquer où trouver le fichier kickstart pour automatiser l'installation.
                    • [^] # Re: Non évènement

                      Posté par  . Évalué à 3.

                      C'est cool, kickstart, bootp/tftp, PXE, tout ca. Ca fait quand meme un poil lourd pour installer une seule machine...

                      Maintenant je pense que ce a quoi il fait référence, c'est les versions businesscard et netinst des CD d'install Debian. Le premier (32Mo) a juste l'installeur, le 2eme (159Mo) les paquets du systeme de base en plus ; et dans les 2 cas, ca propose une liste de mirroirs officiels depuis lesquels l'installeur va joyeusement télécharger les packages en fonction de ce qui a été demandé.
                      • [^] # Re: Non évènement

                        Posté par  . Évalué à 1.

                        toutafé ;)

                        Et la version "cdrom" , te propose aussi d'aller vérifié les maj lors de l'install (toujours avec une liste de miroirs officiels).
                      • [^] # Re: Non évènement

                        Posté par  (site Web personnel) . Évalué à 1.

                        C'est cool, kickstart, bootp/tftp, PXE, tout ca. Ca fait quand meme un poil lourd pour installer une seule machine...

                        Tout comme avec Debian, tu n'es pas obligé de sortir l'artillerie lourde : il suffit de disposer du fichier « ks.cfg » sur un média accessible lors de la phase d'initialisation (comme une disquette).
                        Et, cela dit, pour pouvoir ré-installer une machine à l'identique, il n'y a guère d'autres méthodes que d'utiliser des outils automatiques. Ce n'est pas plus lourd qu'une procédure rédigée avec les différentes étapes à faire. C'est même plus sûr qu'un être humain, qui peut être tenté de passer outre les recommandations.
                    • [^] # Re: Non évènement

                      Posté par  . Évalué à 1.

                      le kickstart va indiquer à l'installateur où chercher ses paquets et quoi mettre , les paquets seront simplement disponible sur un mirroir de cd redhat/fedora en http (ou autre, nfs, voir smb je pense maintenant est possible)

                      C'est bien beau, mais quand tu a fait tout ça, et qu'il se borne a te dire qu'il trouve aucun paquet... ben tu est très content de savoir qu'il peut le faire ... mais ca serait bien mieux qu'il le fasse!

                      Et encore une fois, c'est pas un problème d'url vu qu'il a trouver l'installateur sur la machine distante.

                      Je ne dis pas que je me suis peut etre trompé qq part... mais ca fait plus de 5 ans que j'installe du linux divers et varié, et j'ai essayé de l'installer pendant toute une journée. Donc je me dis, a tort peut être, que malgré ma maladresse légendaire y'a quand meme une couille dans le potage.

                      Et le réseau marche très bien vu qu'avec debian ce fut fait en moins de 45 minutes.

                      Peut etre les différents miroirs qui avait, tous ceux que j'ai testé, aucun index qui était correct ?
          • [^] # Re: Non évènement

            Posté par  . Évalué à 4.

            Un paquetage RPM (package) est un fichier avec un format spécifique (format RPM).
            Pour gérer ce format de fichier, il y a une bibliothèque (library) qui permet de manipuler les fichiers d'installation (et autres) inclus dans le paquetage RPM.
            Cette bibliothèque permet également d'installer ces fichiers d'installation (entre autres) et de gérer une base de logiciels installé sur le système (plus exactement les paquetages installés).
            Des outils sont également fournis pour donner à l'utilisateur la possibilité..et bien d'installer, de supprimer, de rechercher, etc des paquetages RPM sur le système uniquement.
            Tout cela, c'est RPM.

            Yum n'est qu'un enrobeur pour RPM. Il télécharge le paquetage RPM sélectionné ainsi que ses dépendances (paquetages RPM également), puis les installe et cela en s'appuyant sur les outils et bibliothèque RPM. Yum ne gère pas la base des paquetages RPM installés sur le système. Cette tâche est gérer par RPM en tant que tel.

            Idem pour Aptitude. Aptitude fait confiance à RPM pour faire les installations correctement sur le système.


            alors, est ce que RPM5 (pas le format, l'ensemble des outils;)) est aussi rapide qu'aptitude ?
            (c'est une vrai question)


            Non, ce n'est pas une vraie question puisque Aptitude a besoin de RPM (quelque soit sa version) pour fonctionner. RPM5 n'a pas pour vacation de remplacer Aptitude ou Yum.

            Une vraie question est pourquoi RedHat (et autres distribution) n'ont pas poussé plus en avant le développement de RPM afin de :
            - corriger les bugs
            - faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
            - faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.

            Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide (taille des fichiers télécharger réduite). Quelques projets ont tenté de s'y atteler mais la tâche n'est pas simple.

            RPM ayant stagné pendant pas mal de temps, il était de plus en plus difficile de faire évoluer RPM. De nombreux logiciels ont été distribués sous forme RPM, des chaînes de création automatique de paquetage RPM relativement complexes ont été mise en place pour certains logiciels (le noyau de Redhat par exemple), sans oublier que RPM remplit assez correctement sa tâche...tout cela n'a fait que ralentir les évolutions sur RPM.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 1.

              > - faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre

              Comprend pas.
              Rpm est largement utilisé par les distributions. Si tu dis ça en t'appuyant sur le constat que seul les distributions utilisant rpm utilise rpm, ben seul les distributions utilisant deb utilise deb.
              Je ne crois que deb soit plus portable (rpm est aussi utilisé sur Unix et pas seulement Linux).

              > et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.

              C'est plus simple avec deb ?
              Faire un paquet rpm n'est pas compliqué. Mais c'est comme tout, il faut apprendre.

              > - faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.

              Su le fait depuis longtemps.

              > mais seulement les différences d'une version à une autre.

              C'est fait depuis une version de "référence". S'il y a toto-1, puis toto-2, puis toto-3, lorsque tu va downloadé toto-3, ça va être le diff entre toto-1 et toto-3. Sinon ça fait trop de boulot coté serveur, trop de version à gérer, etc.

              > Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide

              Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.
              • [^] # Re: Non évènement

                Posté par  . Évalué à 1.

                Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.

                Ca peut par contre baisser la charge et la bande passante côté serveur, certe ça prend plus de place mais l'espace disque est moins cher que la bande passante (et tu le paye qu'une fois).


                Etienne
                • [^] # Re: Non évènement

                  Posté par  . Évalué à 1.

                  Il n'y a pas de problème, c'est bien. C'est même carrément génial lorsqu'il y a une petit mise à jour d'OOo.
                  Par contre, il ne faut pas croire que ça va tout accelérer.
            • [^] # Re: Non évènement

              Posté par  . Évalué à 2.

              Non, ce n'est pas une vraie question puisque Aptitude a besoin de RPM (quelque soit sa version) pour fonctionner. RPM5 n'a pas pour vacation de remplacer Aptitude ou Yum.
              Note : bien lire la question avant d'affirmer que je ne sais pas ce que je voulais dire merci.
              s/RPM/deb/

              hint :
              (pas le format, l'ensemble des outils;))
            • [^] # Re: Non évènement

              Posté par  . Évalué à 3.

              >- corriger les bugs

              quels bugs ?

              >- faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.

              rpm est portable. ce sont les disttributions qui choisissent de ne pas utiliser les mêmes version de logiciels , de changer les chemins d'installation etc.

              mais rpm est utilisé même dans des unix. c'est du "portable". un paquet rpm qui installe des fichiers dans /opt/toto marcherait sur fedora, mandriva, suse etc. même debian via alien.

              il marcherait aussi sur les unix avec rpm. il copierait en tout cas les fichiers demandé là où on lui dit.

              bref, le format rpm est portable. aux gens de normaliser les distributions linux pour que je puisse installer le dernier firefox sur toutes mes distribs sans attendre 250 forks.


              @- faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.

              c'est une idée en cours oui.
  • # bsdiff...

    Posté par  . Évalué à 4.

    C'est un peu hors-sujet, mais qqun sait-il pourquoi les distributions ne proposent jamais de rpm "différentiels" ? D'un binaire version n à sa version n+1, je suis sûr que la différence (via bsdiff, xdelta ou sdelta) doit être de taille minime, et pour upgrader ma Mandriva je préfèrerais de loin ne télécharger que la différence plutôt que les packages entiers (surtout pour des gros trucs comme KDE ou OpenOffice !)...
    Peut-être qu'il y a une bonne raison de ne pas le faire ("patcher" via bsdiff a peut-être des inconvénients), mais pour l'instant je ne vois pas !
    • [^] # Re: bsdiff...

      Posté par  . Évalué à 1.

      bsdiff, je ne sais pas ce que c'est.

      Suse l'a fait (ou le fait toujours).
      Fedora va le faire :
      http://fedoraproject.org/wiki/Releases/FeaturePresto
    • [^] # Re: bsdiff...

      Posté par  . Évalué à 1.

      C'est aussi l'une des améliorations de RPM que j'attends avec impatience depuis longtemps.

      La solution retenu par Fedora est de recréer la paquetage installé depuis la base RPM,d'y appliquer le patch téléchargé pour en faire un nouveau paquetage RPM qu'on installalera de façon traditionnelle.
      DeltaRPM fait à peu près la même chose.

      Au final, on a tout de même un nouveau paquetage RPM qui installera des fichiers qui n'auront pas été modifiés.
      • [^] # Re: bsdiff...

        Posté par  . Évalué à 2.

        Presto repose sur deltarpm au passage ...
        D'ailleurs j'utilise Presto depuis Fedora 7 et ça marche super bien.
    • [^] # Re: bsdiff...

      Posté par  . Évalué à 2.

      Parce que c'est très lourd à gérer:

      - pour aller de la version 1 à 2 il te faut 2-1

      - pour aller de la version 2 à 3 il te faut 3-2
      - pour aller de la version 1 à 3 il te faut 3-1

      Et plus il y eu de version d'update proposé, plus ça se complique. A l'arrivée c'est vite ingérable.

      Il semble que Suse y arrive cependant.
      • [^] # Re: bsdiff...

        Posté par  (site Web personnel) . Évalué à 5.

        - pour aller de la version 1 à 3 il te faut 3-1

        Ou bien 2-1 et 3-2, qui existent déja normalement.

        Car pour n versions mieux vaut n - 1 deltas, que n(n-1)/2 :)
  • # SOUS MAC ?

    Posté par  . Évalué à -3.

    Je crois que la vous n'imaginez pas le cadeau offert a Steve Jobs !!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.