Quel avenir pour RPM ?

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
28
déc.
2000
Linux
Après l'éditorial du mois dernier sur Freshmeat qui annoncait un support des RPM pour apt-get réalisé par Connectiva, Slashdot vient de passer une news sur un nouveau package manager pour les RPMs.

Une boite basée en Israel et à Palto Alto (Aduva) développe un manager graphique de packages RPM qui supporte les dépendances comme le fait apt-get (ne ratez pas les screenshots qui perso me laissent perplexes) .

Toutes les distribs basées sur RPM proposent aujourd'hui un outil du genre (type rpmdrake pour MDK). L'avenir des packages RPM et des outils pour le gérer n'est pas très clair... quelles sont vos opinions sur le sujet ?

Aller plus loin

  • # vive les tarballs

    Posté par  . Évalué à 0.

    Perso ça fait un moment que je n'utilise plus les rpm, les dépendances ne sont franchement pas géniales, il suffit qu'on ait installé une lib via les sources et non via un rpm pour qu'il nous envoit sur les roses.

    J'aime beaucoup le système de tarball de la slackware :
    installpkg fichier.tgz
    removepkg fichier

    Jesus
    • [^] # Re: vive les tarballs

      Posté par  . Évalué à 1.

      C'est vrai que RPM a des désavantages (tu en as cité un, on peut parler aussi des options de compilations). J'ai un peu le même pb que toi, j'ai mis un noyau 2.0.35 from sources à la place du 2.0.34 fourni en rpm (RH 5.1) et plus moyen de virer la dépendance.
      Mais c'est son boulot de vérifier les dépendances (tu veux installer un soft mais tu ne sais pas quels libs sont nécessaires), la conformité des fichiers installés par rapport au package original (sécurité) et plein d'autres choses encore. Ds RPM, il ya PM pour Package Manager. C'est un outil très puissant quand on a appris à s'en servir.
      • [^] # Re: vive les tarballs

        Posté par  . Évalué à 0.

        je suis d'accord, parfois la gestion des dependances me demandais des libraires dont j'ignorais l'existance.. et impossible de trouver le package/soft qui la fournisait... donc maintenant je m'en tiens au bon vieu README et INSTALL avec tout ce qu'il faut comme indication a l'interieur, suivi d'un bon coup de ./configure;make;su -c "make install"
        perso c pas plus compliqué, et les options peuvent etre très pratique ( allez utiliser un binaire rpm de xchat qui a été créé avec le support de gnome quand on a rien de gnome sur sa becane :p )

        pour moi les packages.. c pas encore ca.... de plus les editeurs font chacun leur sauce, avec des chemin parfois differents pour les lib ...

        mais il faut avouer que pour quelqu'un qui decouvre le monde linux le rpm s'il est correctement utiliser peut vraiment simplifier la vie...
        • [^] # Re: vive les tarballs

          Posté par  . Évalué à 1.

          le pb c'est que c'est pas tres facile de desinstaller une appli en tar.gz (il en y a souvent partout), peut etre pas sous slack (je connais pas trop), mais meme, pour les dependances, c'est pas ca non plus
          • [^] # Re: vive les tarballs

            Posté par  . Évalué à 0.

            Si tu l'installes, comme c'est souvent le cas par defaut, sous /usr/local, il y a moindre mal dans la mesure ou tu as pris soin de desinstaller l'eventuel rpm binaire qui faisait le meme office avant.
            Exemple typique : Apache sur RH. rpm -e (en mettant de cote peut-etre le script de demarrage/stop sous /etc/rc.d/init.d histoire de l'adapter plus tard ;-) ) et ensuite une reinstallation du tar.gz et ./configure "d'origine" ou presque sous /usr/local/src.
            Idem pour d'autres softs qui evoluent vite (PostgreSQL ou PHP par exemple).
            Il est sur que dans ce cas, il faut etre rompu aux arcanes des recompilations de tout ca en meme temps.

            On en arrive a quelquechose de plus propre, avec un "core" de la distribution qui evolue en rpm et quelquechose de plus personnel sur lequel on veut avoir plus de prise (ou reactivite quant a la disponibilite des dernieres moutures...) sous /usr/local/.

            De ce que j'ai vu de ma rapide incursion sous FreeBSD, c'est un peu organise de la sorte (et avis personnel, c'est plus propre).

            Pour le reste, les tar.gz comportent souvent un fichier .spec qu'il suffit eventuellement d'adapter pour le cas personnel et un rpm -ta <tarball> permet de regenerer a partir des sources le rpm source, binaire qui va bien.

            La gestion de package est de toute facon l'element essentiel pour qu'une distribution tienne la route. Sans ca, ca devient ingerable et on perd plus de temps a bricoler et a rendre le systeme pourri non pas seulement en termes de fonctionnalites mais aussi de maintenance.

            Meme Microsoft l'a pige maintenant en reinstallant des DLL essentielles au systeme eventuellement sur des DLL qui viennent d'etre installees par une appli, ce afin de conserver l'integrite du systeme parfois au depend du bon fonctionnement d'une appli.
            Apres tout, il est surement plus important d'avoir la base installee de l'OS propre qu'un truc qui merde parce que les applis installees ont aide a le veroler. Ceci est valable au moins sous sous Windows 2000 mais aussi sur Linux ou autre, gere par les pre et post installations qui sont des elements essentiels des gestionnaires de package, avec la gestion de signature (cf intervention precedente).

            Voir l'excellent bouquin disponible en ligne sur les fonctionnalites des RPM : http://www.rpm.org/(...) chapitre Documentation, disponible au format PostScript ou LaTeX. Interessant pour comprendre la gestion de packages.
            • [^] # Re: vive les tarballs

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

              Réglons tous ces problèmes et installons Debian ;-)

              Au début que j'étais sous linux aussi je me débattais avec les dépendances, jusqu'à en comprendre le fonctionnement, ce qui facilite la chose quand-même, mais quand on débute...

              Enfin, il y a presque 2 ans, j'ai installé Debian, et depuis, j'installe et désinstalle des softs facilement...

              Espérons que l'apt-get sur rpm permettra cela, mais je n'y crois pas à cause de la fragmentation au niveau des packages rpm.

              • [^] # Re: vive les tarballs

                Posté par  . Évalué à 1.

                Le problème des softs récents est toujours là, et je trouve que c'est bcp plus souple les sources que les binaires
          • [^] # Re: vive les tarballs

            Posté par  . Évalué à 1.

            sous slack, il y a un très bon outil (pas dans la distrib officielle, je crois, mais qui marche très bien) qui s'appelle checkinstall. C'est très simple, au lieu de tapper make install, vous faites checkinstal ou checkinstall "make install"
            le prog sera installé, et mis dans la base de donnée des pkgs installés, il sera donc desinstalable d'un simple removepkg machin. C'est franchement très pratique, et ça merite d'être connu. Les developpeurs de ce machin ont d'ailleurs prévu de le rendre compatible avec les systemes de package rpm et deb il me semble, ce qui éviterait peut-être les problemes de dépendance pour les packages installés depuis les sources.
        • [^] # Re: vive les tarballs

          Posté par  . Évalué à 1.

          Je ne "découvre" pas Linux, ce qui ne m'empêche pas d'apprécier la puissance de rpm. exemples divers :
          * scripts d'installation (avant et après copie des fichiers),
          * scripts de désinstallation (avant et après suppression),
          * signature pgp,
          * stockage des tailles, dates, droits et sommes md5 des fichiers installés,
          * description des packages (texte, auteur, date de compil, machine, ...),
          * séparation des fichiers de développement (entêtes) et de production (.so et exécutables) (cas des librairies),
          * pas besoin de compiler à chaque installation (je sais, pour les tarballs de slackware ya pas besoin de recompiler),
          * capacités d'interrogation importantes,
          bref que du bon.
          • [^] # Re: vive les tarballs

            Posté par  . Évalué à 0.

            oui.. tout a fait.. je ne met pas en cause le système de packaging qui est bien fait, mais le fait que l'on est obliger d'utiliser le soft dans le rpm tel que l'auteur du package l'a fait, impossible de ne pas posseder telle ou telle librairie optionnelle si le soft a été compilé avec,.. alors qu'avec un "./configure --disabled-gnome" par exemple... c'est souvent faisable.. maintenant j'utilise moi aussi des rpm.. mais seulement ceux du site de l'editeur de ma distrib, car je suis sur que les dependances seront correctes et qu'il n'y aura pas de pb si je met un rpm prevu avec des liaison de redhat sur ma suse ....
            • [^] # Re: vive les tarballs

              Posté par  . Évalué à 1.

              Il y a tjrs la possibilité de recompiler un rpm ou de compiler une appli et l'installer ds /usr/local/ (j'ai installé gnome 1.0.51 ds /usr/local/, j'en ai chier mais ça tourne). Et si toutes les distrib avaient le même plan de stockage de fichiers (comme le FSSTND).

              Les deux points de vue se valent, l'important étant d'avoir le choix.
    • [^] # Re: vive les tarballs

      Posté par  . Évalué à 0.

      Si les rpm faisait un check des libs, plutot que des rpms, ça serait franchement bien, un truc du style :

      ldconfig -p | grep libmachin

      pour savoir si la lib machin est la, et dans la bonne version, mais pas forcément en mode rpm.

      pour ce qui est de Debian je ne connais pas ses packages ...

      pour le moment je reste sur le système tarball de la slack, qui contiennent :
      . les binaires
      . un script d'install
      . un script de remove
      le tout gérer par 2 utilitaires (installpkg|removepkg), mais il est vrai qu'il ne fait de checkup des dépendances, ce qui peut poser des problèmes pour les débutants.

      Jesus
      • [^] # Re: vive les tarballs

        Posté par  . Évalué à 1.

        Tu peux forcer le rpm à requérir un package particulier (ou une librairie) avec une version particulière (inférieure, supérieure ou égale à une valeur).
    • [^] # Re: vive les tarballs

      Posté par  . Évalué à 0.

      Désolé, mais même les packages debian pose se genre ce problème.

      Lorsque j'ai compilé une librairie, le système des packages me crie dessus parce que je n'est pas cette librairie ...

      En tout cas, les packages debian sont plutôt les meilleurs
      (et pourtant, j'en est testé des distrib' boudiou !! ;)
  • # screenshots

    Posté par  . Évalué à 1.

    effectivement .... rien que le screenshots du main me parait ..comment dire .... 'inbitable '( :) )bon gvais tester kan meme
    c ou kon d/l ?
    • [^] # Re: screenshots

      Posté par  . Évalué à 1.

      Tu vas sur le site et e bas y a un lien download

      voila voila voila.
    • [^] # Re: screenshots

      Posté par  . Évalué à 0.

      En effet, ça me fait penser à un bel emballage avec une grosse m.... dedans.

      C'est visuellement lourd et lassant (un peu comme le Aqua de MacOS).

      (imbitable, avec un 'm' et pas un 'n').

      Sur debian, on a apt-get pour la ligne de commande, aptitude en ncurses, gnome-apt pour les furieux de la souris.

      Et les dépendances sont gérées aussi pour les paquets sources (pas pour tous, d'accord).

      -- Charles (charles.goyard@laposte.net)
      • [^] # Re: screenshots

        Posté par  . Évalué à 0.

        "En effet, ça me fait penser à un bel emballage avec une grosse m.... dedans"

        Puis-je savoir en quoi c'est de la merde ? AH oui, excuse moi, ca ne rentre pas dans ton monde monochrome ...

        He les mecs, faut peut etre arrete un peu d'etre fasciste et etaleur de confit.

        Si un tel logiciel existe, c'est qu'il y a une demande, et tant pis si les gnomes (dans tout les sens du terme) n'aiment pas ...

        Cet manie de tout le temps penser que l'on est le meilleur parce que on utilise tel outil et pas tel autre montre bien l'etat d'esprit pueril general qui regne ici.

        Toi qui est si prompt a traiter ce soft de "grosse merde", fait mieux, vas-y, produit un soft qui tue tout sur son passage, tu doit en etre capable puisque tu te permet de traiter le travail des autres de "merde".

        • [^] # Re: screenshots

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

          Le pb avec des applis comme ça, c'est que si tu refais une interface graphique tu ajoutes beaucoup de code a ton appli, donc beaucoup de bugs potentiels, alors qu'en utilisant une librairie graphique existante (KDE, GTK, Athena, wxWindows, Lesstif... c'est pas ce qui manque) tu peux te concentrer sur le but de l'appli (Ici gérer des paquets) et pas sur la couleur du dégradé du bouton (Dont l'utilisateur qui veut mettre à jour son système se contrefiche)
          • [^] # Re: screenshots

            Posté par  . Évalué à 0.

            L'appli est faite avec QT, c'est pas plus lourd qu'autre chose !

    • [^] # Retour d'expérience...

      Posté par  . Évalué à 0.

      Si tu peux nous faire un résumé après tes tests, ça m'intéresse (auteur de la news : Foxy) car comme je l'ai dit, à la vue des screenshots, j'ai plutôt tendance à fuir.

      Désolé mais j'ai du mal à retenir le mot de passe (j'en manipule déjà 15 par jour...) pour m'authentifier.
      • [^] # Re: Retour d'expérience...

        Posté par  . Évalué à 1.

        Tu peux les changer, non ? j'en utilise que 3 ds une dizaine d'identification (pas très sûr mais ce n'est pas des données essentielles).
      • [^] # Re: Retour d'expérience...

        Posté par  . Évalué à 0.

        Bon ben 40 Mo de correctifs/mises à jour de librairies, dont XF86, c'est un peu beaucoup (surtout avec une connexion RTC à 33.6 K= déjà 2heures de connexion ;-(). D'autant plus que la mise à jour se fait sur une SuSe 7 installée fraîchement. Je me demande si cet Aduva (Aduvizor) met à jour les liens ou propose les dernières versions des paquets.ça change de rpmfind - qui n'a pas la même vocation, c'est vrai. Pour l'instant je vais boire mon thé. A bientôt pour un "retour" plus précis. désolé pour l'anonymat.
        Adimante
  • # Ca existe deja

    Posté par  . Évalué à 1.

    Ben oui et KPackage/GnoRPM alors?
    • [^] # Re: Ca existe deja

      Posté par  . Évalué à 1.

      et Midnight Commander ?
      • [^] # Re: Ca existe deja

        Posté par  . Évalué à 1.

        Et la bonne vieille ligne de commande ?
        • [^] # Re: Ca existe deja

          Posté par  . Évalué à 1.

          oui mais ca va pas pour n'importe qui (ex : les gens qu'ont un mulot greffé dans la main)
  • # Paquet ok, mais c ki ki les fait ?

    Posté par  . Évalué à 1.

    Je crois bien que je peux me tromper que la
    force de debian est ,ou plutot, sont les developpeurs debian.
    Est-ce que le probleme n'ai pas plutot qui fait
    les paquets ? car cette personne a potentielement les droits roots sur les machines ou est installe son paquet ...
    ( desole pour le titre neuneu, oups je vais encore me faire attraper par la gente feminine :).
    • [^] # Re: Paquet ok, mais c ki ki les fait ?

      Posté par  . Évalué à 1.

      Heu, desole ->
      Je crois,(virgule) bien que je puisse me tromper, (virgule) que la force de debian est ....
      Tout le monde aura compris :)
      ( desole pour le probleme n'est ... :(.
      Pas la peche aujourd'hui :(.
    • [^] # Re: Paquet ok, mais c ki ki les fait ?

      Posté par  . Évalué à 1.

      Pour ce qui est la fabrication de paquets, n'importe qui peut le faire à condition de configurer rpm (~/.rpmrc ?) car par défaut il utilise /usr/src/redhat qui est en root:root rwx.r-x.r-x. Pour l'installation/suppression/update, il me semble que c'est réservé au super-user.
    • [^] # Spécial paranos!

      Posté par  . Évalué à 1.

      Voici comment inspécter des RPMs douteux :

      rpm -qpl lerpm.rpm <- liste les fichiers qu'il contient *ou* qu'il va s'accaparer
      rpm -qpi lerpm.rpm <- donne des infos sommaires (et facilement falsifiables comme le build host, attention!)
      rpm -qp --scripts lerpm.rpm <- va lister tous les scripts executés avant/après l'installation et avant/après la désinstallation
      rpm -K lerpm.rpm <- vérifie le md5 du fichier et sa signature pgp ou gpg si elle est présente

      Après avoir fait le tour d'un RPM avec tout ça et s'il n'y a rien d'anormal, le rique le plus évident est écarté... ensuite reste à voir le contenu des fichiers installés :-)
      • [^] # Re: Spécial paranos!

        Posté par  . Évalué à 0.

        y a aussi rpm -qp --changelog lerpm.rpm qui
        te donne toutes les modifs ( seulement si les packageurs
        ont fait l effort de mettre leurs modifs...)
  • # La diversité des distributions à base de RPM

    Posté par  . Évalué à 1.

    * Beaucoup soulignent les problèmes liés aux dépendances dans les RPMs avec comme argument que la Debian implémente un système bien meilleur
    * D'autres soulignent qu'ils préfèrent installer depuis les sources...

    Personnellement j'adore les RPMs car c'est le juste milieu entre ces deux opinions! Je m'explique :
    Les dépendences ne sont pas *automatiquement* gérées et ça, personnellement j'adore! Si je disais "je veux ce jeu pourri" et qu'au final j'avais 150Mo de librairies en tout genre sans rien avoir demandé, je n'aimerais pas... (j'ai volontairement poussé l'exemple à l'extrème)
    D'un autre côté, en installant depuis les sources il manque souvent d'autres packages qu'il faut aller récupérer ici ou là et... recompiler à chaque fois! Il faut aussi tout recompiler autant de fons qu'on a de machines... mais c'est pas là le pire, le pire c'est pour faire des mises à jour! Je ne dis pas que c'est dur, mais simplement que c'est complexe pour pas grand chose : sauvegarder ses fichiers de configuration, prier pour que des fichiers n'aient pas changé d'emplacement...

    Pour moi les RPMs c'est un peu comme les packages slackware ou les ports FreeBSD : C'est bien foutu, mais on garde encore un contrôle total sur ce que l'on fait!

    Un RPM bien fait s'installe à la perfection (dépendances, création de comptes systèmes), se met à jour à la perfection (maintien de l'ancienne conf sauf si le format de fichier a changé) et se désinstalle à la perfection (sauvegarde des fichiers de conf uniquement s'ils ont été modifiés).

    Le seul point négatif que je trouve aux RPMs, c'est qu'étant donné la diversité des distributions qui utilisent ce "format", et vu qu'elles n'ont pas toutes le même fonctionnement pour certaines parties (scripts d'init, arborescence de confs...), il est impossible de faire un seul RPM binaire par architecture...

    Personnellement je n'utilise plus que des RedHat 7.0 depuis sa sortie, et je n'ai _JAMAIS_ rien installé à partir des source (à part des noyaux ;-). Ce que je fais, c'est que je crée un RPM moi-même (s'il n'en existe pas déjà un fait par RedHat ou par l'auteur) et je le met à disposition de tout le monde... bien souvent d'ailleurs (pour gkrellm et lbreakout par exemple), je me retrouve à faire les RPMs "officiels". C'est une façon comme une autre de contribuer :-)

    Tous mes RPMs pour RedHat 7.0 (xine, gkrellm, tuxracer, ircd, lame, nessus, proftpd et beaucoup d'autres) :
    http://www.aldil.org/ftp/(...)

    Longue vie à Linux et à sa diversité ;-)

    Matthias
  • # make install

    Posté par  . Évalué à 0.

    Est-ce qu'il y a pas un outil qui au moment du "make install" pour créer un rpm (ou deb, tar.gz etc...)? Histoire que la desinstall se fasse de manière plus propre. Bon je suppose qu'il faut adapter la génération du ./configure, etc pour indiquer les fichiers de conf, les lib necessaire pour le rpm, etc... Mais si ca existerais (pour moi qui fonctionne avec la slack et du compilé), ca serait achement kewl
    • [^] # Re: make install

      Posté par  . Évalué à 0.

      En bricolant un peut, on doit pouvoir faire ça. Du genre un script qui fait "make install prefix=<un endroit temporaire>" puis un ls -lR du rép temporaire ds un fichier listing pour avoir la liste des fichiers installés.
      • [^] # Re: make install

        Posté par  . Évalué à 0.

        ./configure --prefix=/opt/nomdusoft
        t'ajoutes /opt/nomdusoft a ton PATH
        et quand tu veux le virer rm -rf /opt/nomdusoft en tout cas ca marche chez moi
        • [^] # Re: make install

          Posté par  . Évalué à 1.

          tu peux aussi créer un répertoire /opt/jumble
          (jumble signifie "fourre-tout" en anglais) avec
          dedans des répertoires bin, lib, etc, share ...
          Les répertoire lib et bin contiendront des liens
          symboliques vers les fichiers des réps. bin et lib de chaque package (attention aux conflits éventuels de noms). share contiendra des liens les répertoires share des applis. etc ... soit des liens vers les fichiers des divers etc/ ou d'autres structures au choix ...
          J'allais oublier: même principe avec sbin/, et man/man*/, doc/, info/ et include/

          Qd tu supprimes/mets à jour un package, tu supprimes les symlinks vers le package supprimé. C'est facile à faire avec un ls -l | grep repappli | awk '{print $9}' . Y a mieux que awk mais je sais plus faire.
          Reste à rajouter /opt/jumble/lib dans ton LD_LIBRARY_PATH, voire dans /etc/ld.so.conf et /opt/jumble/bin dans ton PATH.

          Je tourne sous Debian Woody, mais certaines applis ne sont pas dispo en .deb. J'utilise donc ce système pour compiler des progs. En plus, tout les progs compilés maison étant dans /opt, un tar | rsh suffit pour le copier sur une autre machine. J'ai ainsi compilé AfterSte 1.8.4, xmps, ... et aussi mis StarOffice, quake3 ... qui n'ont pas vraiment leur place ailleurs (peut-être dans /usr/local, mais je ne me sers pas de cet emplacement).
    • [^] # Re: make install

      Posté par  . Évalué à 0.

      Généralement, tu fais :

      ./configure --prefix=/usr (par exemple)
      make

      Pour installer et avoir la liste des fichiers installés, tu as juste à créer un package slackware comme suis dans 99,80% des cas :

      make prefix=$PWD/fakeRoot/usr install

      Dans fakeRoot, tu auras l'arborescence des fichiers qui seront installés. Si tu es sous Slackware comme tu l'as dit, tu fais :

      cd fakeRoot
      su
      chown root.root -R *
      makepkg packagename.tgz (voila un pkg slack !)
      installpkg packagename.tgz

      Dans /var/log/packages/packagename, tu auras la liste des fichiers installés. Pour désinstaller proprement, tu fais removepkg packagename.

      Efficace, propre, slackware bref ;-) Parfois, ça ne fonctionnera pas car le make install devra changer le propriétaire, ajouter des utilisateurs et tuti quanti. Dans ce cas, tu peux utiliser installwatch (cherche avec google) pour avoir la liste des fichiers installés puis créer ton prpore package slack si tu es sous Slack.

      Notez que si vous n'êtes pas sous Slack, installwatch est assez pratique pour voir ce qui a été installé, modifier, etc.

      Bref, chacun sa distro, chacun ses choix : tout dépend des besoins de chacun (pour peu qu'on passe le temps à les évaluer et à se renseigner sur les distros bein sûr).

      LiNuCe !


  • # C'est pas dans la LSB ?

    Posté par  . Évalué à 0.

    Il me semble que les packages RPM font partie (ou vont faire partie) de la LSB (Linux Standard Base), non ? Donc, comme tous les Linux qui vont devoir plus ou moins se conformer a la meme hierarchie de filesystem, il y a des chances aue le RPM se generalise encore plus qu'actuellement (RH + MDK + Suse)...
    • [^] # Re: C'est pas dans la LSB ?

      Posté par  . Évalué à 0.

      C'est un fait que beaucoup de distros utilisent RPM, et c'est justement ce qui fait que je n'utilise que debian. Je m'explique pour éviter un troll.

      Quand je désire récupérer un programme au format RPM je suis obligé de vérifier pour quelle distrib il a été compilé, en effet :

      1) Suivant la distro d'origine, les dépendances du programme seront non résolues.

      2) Les programmes installeront des fichiers dans des répertoires qui n'existaient pas avant. (exemple /usr/doc à la place de /usr/share/doc)

      Donc le programme que je récupère n'est pas forcément fonctionnel.

      Après avoir pendant des années fonctionné en réinstallant régulièrement mes distros puisque les dépendances craignaient trop pour laisser un système stable j'ai décidé de me mettre à la debian depuis quelques mois. Parceque les personnes qui développent les deb utilisent tous la même file hérarchie, les mêmes lib etc.

      Maintenant je ne dis pas que deb est meilleur que RPM, je pense juste que pour l'utilisateur final le format deb est moins générateur de problèmes que le format rpm.

      La FHS va peut être changer les choses mais j'en doute parceque dans un milieu économique je vois mal les distros chercher à faire du standard et donner leurs programmes phares aux autres distros (avis personnel, troll bare en booleen, SVP!). Et ca c'est dommage parceque franchement je ne vois pas l'avantage du deb sur les rpm ou vice versa, c'est juste la question de la philosophie sous-jacente qui me gène.
  • # Simplicité et clareté

    Posté par  . Évalué à 0.

    les rpms ont cet avantage indéniable pour tout utilisateur linux , ils ne nécessitent qu un minimum d'effort : install du package , des packages lié si besoin ai , et hop finito . Les sources ont cet inconvéniant qu'ils nécessitent un ptit boulot quand même... pis je parle pas qd ça bug : en rpms , bah ont sais que ca viens du package et on en cherche ailleur / avec des sources ont se demandent toujours si c nous qui avons merdé qqpart ou si c le prog qui ai mal écris ... et ceci , pour un néophite comme pour un utilisateur moyen . Dc je suis plutot pour les rpms ...

Suivre le flux des commentaires

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