Quels sont les avantages / inconvénients de deb vs. rpm?


173

Pour une raison quelconque, j'ai toujours utilisé des distributions basées sur RPM (Fedora, Centos et actuellement openSUSE). J'ai souvent entendu dire que deb est meilleur que rpm, mais lorsqu'on lui a demandé pourquoi, je n'ai jamais réussi à obtenir une réponse cohérente (obtenez plutôt des rituels zélés et copieux à la place).

Je comprends qu'il y ait peut-être des raisons historiques, mais dans le cas de distributions modernes utilisant les deux méthodes de conditionnement différentes, quelqu'un peut-il expliquer les avantages techniques (ou autres) de l'une par rapport à l'autre?

Réponses:


87

La principale différence pour un mainteneur de paquet (je pense que ce serait un «développeur» dans le jargon Debian) réside dans la façon dont les métadonnées de paquet et les scripts qui l'accompagnent sont combinés.

Dans le monde RPM, tous vos packages (les RPM que vous maintenez) se trouvent dans quelque chose comme ~/rpmbuild. Ci-dessous, vous SPECtrouverez le répertoire pour vos fichiers de spécification, un SOURCESrépertoire pour les archives de code source RPMSet des SRPMSrépertoires dans lesquels vous pouvez ajouter les RPM et les SRPM nouvellement créés, ainsi que d'autres éléments non pertinents à présent.

Tout ce qui concerne la manière dont le RPM sera créé se trouve dans le fichier de spécifications: quels correctifs seront appliqués, pré-et post-scripts possibles, méta-données, changelog, tout. Toutes les archives source et tous les correctifs de tous vos paquets sont dans SOURCES.

Personnellement, j'aime bien le fait que tout soit dans le fichier de spécifications et que ce dernier soit une entité distincte de l'archive source, mais je ne suis pas très enthousiaste à l'idée d'avoir toutes les sources dans SOURCES. À mon humble avis, SOURCES devient vite encombré et vous avez tendance à perdre de vue ce qu’il contient. Cependant, les opinions diffèrent.

Pour les RPM, il est important d'utiliser exactement la même archive que celle publiée par le projet en amont, jusqu'à l'horodatage. En règle générale, il n'y a pas d'exception à cette règle. Les paquets Debian requièrent également la même archive que celle utilisée en amont, bien que la politique Debian exige que certaines archives soient reconditionnées (merci, Umang).

Les paquets Debian adoptent une approche différente. (Pardonnez les erreurs ici: j'ai beaucoup moins d'expérience avec deb que avec RPM.) Les fichiers de développement des paquets Debian sont contenus dans un répertoire par paquet.

Ce que j'aime (pense) dans cette approche est le fait que tout est contenu dans un seul répertoire.

Dans le monde Debian, il est un peu plus accepté de transporter des correctifs dans un paquet qui n'est pas (encore) en amont. Dans le monde RPM (du moins parmi les dérivés de Red Hat), cela est mal vu. Voir "FedoraProject: Rester proche des projets en amont" .

En outre, Debian dispose d’un grand nombre de scripts capables d’automatiser une grande partie de la création d’un paquet. Par exemple, créer un paquetage - simple - d’un programme Python défini par setuptool, est aussi simple que créer deux fichiers de méta-données et l’exécuter debuild. Cela dit, le fichier de spécifications pour ce type de paquet au format RPM serait assez court et, dans le monde des RPM, beaucoup de choses sont automatisées de nos jours.


9
Pour vous corriger sur les paquets Debian, le debianrépertoire existe dans le répertoire dans lequel la source amont a été extraite, et Debian valorise beaucoup le concept d’une archive source vierge en amont. Lorsqu'un paquet source est construit, trois fichiers (deux pour les paquets natifs) sont appelés ensemble: le fichier compressé en amont (de préférence vierge, la politique Debian requiert le reconditionnement de certains projets), un fichier compressé du répertoire debian pour le fichier. nouveau format 3.0 (un diff pour l’ancien format 1.0) et un fichier .dsc.
Umang

8
Le répertoire debian ne va pas dans l'archive amont, il reste dans le .diff.gzou les .debian.tar.gzfichiers du paquet source, bien que le debianrépertoire se trouve à l'intérieur de l'arbre source lors de l'extraction du paquet source. BTW: lorsque la stratégie ne nécessite pas de reconditionnement, le MD5 de l'archive doit correspondre à l'archive en amont. De plus, pour clarifier, les correctifs faits par le mainteneur de la source en amont sont stockés dans le répertoire debian (format source 3.0) et dans le .diff.gz(format 1.0).
Umang

Umang, merci pour votre correction. Je vais supprimer la partie sur la modification de l'archive en amont pour m'assurer que personne ne comprend la mauvaise idée.
wzzrd

2
Ça a l'air bien maintenant, sauf que vous avez toujours un "Pour RPM, il est important d'utiliser exactement la même archive que celle publiée par le projet en amont, jusqu'à l'horodatage." En raison de mon manque total d'expérience avec les RPM, je ne sais pas si la différence de politique est énorme, mais comme je l'ai dit, un développeur Debian insistera pour qu'il soit exact à l'horodatage, sauf si l'archive en amont enfreint la politique de Debian et doit être reconditionné.
Umang

7
@wzzrd, il est en fait facile de regrouper vos fichiers source dans un répertoire par package, en définissant% _specdir et% _sourcedir dans votre fichier ~ / .rpmmacros.
mattdm

95

Beaucoup de gens comparent l'installation de logiciels apt-getà rpm -i, et disent donc mieux que DEB. Cela n'a cependant rien à voir avec le format de fichier DEB. La vraie comparaison est dpkgvs rpmet aptitude/ apt-*vs zypper/ yum.

Du point de vue de l'utilisateur, il n'y a pas beaucoup de différence entre ces outils. Les formats RPM et DEB ne sont que des fichiers d’archive, auxquels sont attachées des métadonnées. Ils sont tous les deux également mystérieux, ont des chemins d’installation codés en dur (beurk!) Et ne diffèrent que par des détails subtils. Les deux dpkg -iet rpm -in'ont aucun moyen de savoir comment installer des dépendances, sauf si elles sont spécifiées sur la ligne de commande.

En plus de ces outils, il existe une gestion de référentiel sous la forme de apt-...ou zypper/ yum. Ces outils téléchargent des référentiels, suivent toutes les métadonnées et automatisent le téléchargement des dépendances. L'installation finale de chaque package est confiée aux outils de bas niveau.

Pendant longtemps, le apt-gettraitement de l’énorme quantité de métadonnées a été supérieur au temps yumnécessaire pour le traitement . RPM souffrait également de sites tels que rpmfind où vous trouveriez plus de 10 packages incompatibles pour différentes distributions. Aptcomplètement caché ce problème pour les paquets DEB car tous les paquets ont été installés à partir de la même source.

À mon avis, zyppera vraiment réduit l'écart aptet il n'y a aucune raison d'avoir honte d'utiliser une distribution basée sur RPM de nos jours. C’est aussi bien, sinon plus facile, à utiliser avec le service openSUSE build à la portée de la main pour obtenir un énorme index de paquetage compatible.


@Tshepang: corrigé
vdboor

13
À mon avis, j'ai méprisé RPM pour la raison exacte que vous avez mentionnée: "RPM souffrait également de sites tels que rpmfind où vous trouveriez plus de 10 packages incompatibles pour différentes distributions." De plus, je trouve extrêmement difficile de trouver un RPM pour les logiciels dont j'ai besoin. Alors que pour DEB: "Apt a complètement caché ce problème pour les paquets DEB car tous les paquets ont été installés à partir de la même source." qui sont vraiment faciles à trouver et à utiliser. De plus, DEB semble toujours mieux trouver et installer des dépendances alors que RPM m'a toujours laissé pendre ... mon avis après 15 ans d'utilisation des deux!
Jeach

2
Je pense que cette réponse répond à la question du point de vue du consommateur, contrairement à @ wzzrd qui est entièrement centré sur le développeur / emballeur. En outre, très clair sur la séparation de niveau.
GnP

1
Votre texte a été copié sur WikiVS , semble être attribué correctement.
Martin Ueding

1
Du point de vue de l'utilisateur, c'est la meilleure réponse. Et j'ajouterais que l'utilisation des PPA est beaucoup plus simple que d'ajouter un nouveau référentiel yum.
Marco Sulla

39

Du point de vue de l'administrateur système, j'ai trouvé quelques différences mineures, principalement dans le jeu d'outils dpkg / rpm plutôt que dans le format du paquet.

  • dpkg-divertpermet à votre propre fichier de remplacer celui provenant d'un paquet. Cela peut vous sauver la vie si vous avez un programme qui cherche un fichier /usrou /libqui ne prend pas /usr/localde réponse. L'idée a été proposée, mais pour autant que je sache, non adoptée, en tours / minute.

  • Lorsque j'ai administré pour la dernière fois les systèmes basés sur rpm (ce qui était *.rpmsavevrai il y a des années, la situation s'est peut-être améliorée), rpm écrasait toujours les fichiers de configuration modifiés et transférait mes personnalisations dans (IIRC). Cela a rendu mon système non démarrable au moins une fois. Dpkg me demande quoi faire, tout en conservant mes personnalisations par défaut.

  • Un package binaire rpm peut déclarer des dépendances sur des fichiers plutôt que sur des packages, ce qui permet un contrôle plus précis qu'un package deb.

  • Vous ne pouvez pas installer un package rpm version N sur un système doté de la version N-1 des outils rpm. Cela pourrait aussi s'appliquer à dpkg, sauf que le format ne change pas aussi souvent.

  • La base de données dpkg est constituée de fichiers texte. La base de données rpm est binaire. Cela facilite la recherche et la réparation dans la base de données dpkg. D'autre part, tant que rien ne va pas, rpm peut être beaucoup plus rapide (installer un deb nécessite de lire des milliers de petits fichiers).

  • Un paquet deb utilise des formats standards ( ar, tar, gzip) afin que vous puissiez inspecter, et dans un tweak de pincement) paquets deb facilement. Les forfaits RPM ne sont pas aussi sympathiques.


2
On dirait que ces jours-ci, il enregistre le nouveau fichier de configuration au *.rpmnewlieu de modifier votre fichier modifié - du moins sur openSUSE.
Evan

1
Les deux sont terminés, vous obtenez donc une dispersion des fichiers rpmsave et rpmnew.
Burhan Ali

4
Vous vous trompez sur le fait que les RPM n'utilisent pas de formats standard. RPMS utilise CPIO pour la section de données - qui est un format d’archive standard. Les autres sections sont principalement des en-têtes. Vous pouvez utiliser l'outil rpm2cpio pour extraire uniquement la section de données du RPM et extraire les fichiers contenus dans le rpm. Par exemple: rpm2cpio foobar.rpm | cpio -idmv
Tuxdude

... et il y en a rpm2cpio.shpour les inclinés.
Michael Shigorin

La seule rupture changement dans le debformat que je me souviens est alors data.tar.gzdevenu data.tar.xz, à quel point plus dpkgcessé d' être en mesure d'ouvrir de nouveaux packages.
mtraceur le

19

RPM:

  • 'Standardisé' (pas qu'il n'y ait pas de spécification deb)
  • Utilisé par de nombreuses distributions différentes (mais les paquetages d'un fichier ne fonctionnent pas nécessairement sur un autre)
  • IIRC autorise les dépendances sur les fichiers, pas seulement sur les paquets

DEB:

  • Popularité croissante
  • Permet des recommandations et des suggestions (le RPM éventuellement plus récent le permet également)

La question la plus importante est probablement le gestionnaire de paquets (dpkg vs yum vs aptitude, etc.) plutôt que le format de paquets (car les deux sont comparables).


6
La "popularité croissante" n'est-elle pas fondamentalement "Ubuntu est basée sur Debian, et alors, vous savez, vous y allez?"
mattdm

"dpkg vs yum" n'est pas la bonne comparaison, car le premier est un gestionnaire de paquets, mais le dernier ne l' est pas (tout comme apt / aptitude sont des gestionnaires de niveau de référentiel plutôt que simplement "un paquet").
Michael Shigorin

14

Comme plusieurs intervenants l'ont dit, ce n'est pas tellement qu'un format de paquet est clairement supérieur. Techniquement, ils peuvent être plus ou moins comparables. De mon point de vue, beaucoup de différences, et pourquoi les gens préfèrent l’une à l’autre, ont à voir avec:

  • La philosophie de l'emballage d'origine et le public cible
  • La taille de la communauté et, par extension, la qualité et la richesse des dépôts

Philosophie:

Dans le monde Ubuntu / Debian / Mint / ..., les utilisateurs s'attendent à ce que le paquet installé "fonctionne" une fois installé. Cela signifie que lors de l’installation, les packages doivent prendre en charge tout le nécessaire pour leur bon fonctionnement, y compris, mais sans s'y limiter:

  • mise en place des tâches cron nécessaires ou facultatives
  • mise en place d'alternatives / alias
  • mise en place de scripts de démarrage / arrêt
  • y compris tous les fichiers de configuration nécessaires avec des valeurs par défaut qui ont du sens
  • conserver les anciennes versions des bibliothèques et ajouter les liens symboliques versionnés appropriés aux bibliothèques (.so) pour assurer la compatibilité descendante
  • support clair pour les binaires multi-arch (32 et 64 bits) sur la même machine, etc.

Dans le monde des rpm - il est vrai que c’était la situation il ya plusieurs années et que la situation s’est peut-être améliorée depuis - je me suis trouvé dans l’obligation de lancer des étapes supplémentaires (par exemple, chkconfig, ce qui permet de créer des tâches cron) pour que les packages fonctionnent réellement. Cela peut convenir aux administrateurs système ou aux personnes qui connaissent Unix, mais cela fait souffrir les expériences des débutants. Notez que ce n'est pas le format du paquet RPM lui-même qui empêche cela, mais que de nombreux paquets ne sont de facto pas "complètement faits" du point de vue d'un débutant.

Taille de la communauté, participation et richesse des dépôts:

La communauté ubuntu / debian / mint / ... étant plus grande, le nombre de personnes impliquées dans les logiciels de packaging et de test est plus important. J'ai trouvé la richesse et la qualité des référentiels supérieurs. Dans Ubuntu, j'ai rarement, voire pas du tout, besoin de télécharger le code source et de le construire. Lorsque je suis passé de Red Hat à Ubuntu chez moi, le référentiel RHEL type contenait environ 3 000 packages, alors qu’en même temps, ubuntu + univers + multivers, tous disponibles directement à partir d’un miroir Canonical, contenait environ 30 000 packages (environ 10x). La plupart des paquets que je cherchais au format RPM n'étaient pas facilement accessibles via une simple recherche et un clic dans le gestionnaire de paquets. Ils ont nécessité de passer à d’autres référentiels, de rechercher sur le site Web du service rpmfind, etc. Ceci, dans la plupart des cas, ne interrompu mon installation en ne limitant pas les dépendances pouvant ou non être mises à niveau correctement. Je frappe le phénomène "dépendance enfer", comme décrit ci-dessus par Shawn J. Goff.

En revanche, dans Ubuntu / Debian, j’ai constaté que je n’avais presque jamais besoin de construire à partir des sources. Aussi à cause de:

  • Cycle de publication rapide d'Ubuntu (6 mois)
  • L'existence de PPAs entièrement compatibles qui fonctionnent immédiatement
  • Les référentiels à source unique (tous hébergés par Canonical) ne nécessitent pas de rechercher des repos alternatifs / complémentaires
  • Expérience utilisateur transparente, d'un clic à l'autre

Je n'ai jamais eu à faire de compromis sur les anciennes versions de paquets qui me tenaient à cœur, même lorsqu'ils n'étaient pas gérés par des développeurs officiels (Canonical). Je n'ai jamais eu à quitter mon gestionnaire de packages convivial pour l'interface graphique pour effectuer une recherche pratique par mot-clé, pour rechercher et installer les packages que je voulais. De plus, à quelques reprises, j'ai installé des paquets debian (non-Canonical) sur Ubuntu et ils ont très bien fonctionné, bien que cette compatibilité ne soit pas officiellement garantie.

Notez que ceci n’est pas destiné à déclencher une guerre des flammes, c’est simplement partager mon expérience après avoir utilisé les deux mondes en parallèle pendant plusieurs années (travail vs domicile).


Il s'agit plutôt de "redhat vs canonical" (avec une récolte canonique de ce que fait Debian depuis deux décennies) et non de "rpm vs deb" - je le dis en tant que membre de l'équipe ALT Linux.
Michael Shigorin

Oui, justement. Et bien dit.
arielf

12

Je pense que le biais ne vient pas du format du paquet, mais des incohérences qui existaient dans les dépôts de RedHat.

À l'époque où RedHat était une distribution (avant RHEL, Fedora et Fedora Core), les gens se trouvaient parfois dans «RPM Hell» ou «dépendance Hell». Cela se produisait lorsqu'un référentiel se retrouvait avec un paquet ayant des dépendances (plusieurs couches, généralement) qui s'excluaient mutuellement. Ou bien cela se produirait lorsque deux packages différents comportaient deux dépendances mutuellement exclusives. C'était un problème avec l'état du référentiel, pas avec le format du paquet. "L'enfer de RPM" a laissé un dégoût pour les systèmes RPM parmi une population d'utilisateurs de Linux qui avaient été brûlés par le problème.


8

Il y a aussi la différence "philosophique": dans les paquets Debian, vous pouvez poser des questions et bloquer ainsi le processus d'installation. Le mauvais côté de ceci est que certains paquets vont bloquer vos mises à jour jusqu'à ce que vous répondiez. Le bon côté de ceci est, également en tant que différence philosophique, sur les systèmes basés sur Debian, lorsqu'un paquet est installé, il est configuré (et pas toujours comme vous le voudriez) et en cours d'exécution. Pas sur les systèmes basés sur Redhat où vous devez créer / copier à partir de / usr / share / doc / * un fichier de configuration par défaut / template.


6

Une chose que j’aime dans les RPM est l’ajout (récent?) Des RPM delta. Cela facilite la mise à jour et réduit la bande passante requise.

Les DEB sont des fichiers ar standard (avec plus d'archives standard à l'intérieur), les RPM sont des fichiers binaires "propriétaires". Personnellement, je pense que le premier est plus pratique.

Juste deux choses que je peux penser de façon spontanée. Les deux sont très comparables. Les deux ont d'excellents outils pour l'emballage. Je ne pense pas qu'il y ait autant de mérites pour l'un que pour l'autre ou vice versa.


8
Appeler des RPM "propriétaires" est un peu fort. Il y a quelques en-têtes supplémentaires et autres, mais le noyau d'un RPM est une archive cpio compressée avec gzip. Il existe un outil fourni avec RPM appelé rpm2cpio qui vous permet d'extraire ce noyau afin que vous puissiez le jouer comme vous le pouvez avec un fichier .deb.
Warren Young

4
Ordures. Les RPM ne sont pas des fichiers binaires propriétaires. Auparavant, ils étaient construits autour de cpio (qui est vieux, certes, mais pas propriétaire), tandis que les versions plus récentes de RPM utilisent xz, qui est également disponible en open source.
wzzrd

C'est vrai, je l'ai cité, car bien sûr, ce n'est pas vraiment propriétaire et c'est exactement ce que je veux dire: en-têtes supplémentaires, etc., donc ce n'est pas tout à fait un fichier ar simple comme un deb. Pas une affaire énorme, juste une chose mineure.
johansson

5
Peut-être devriez-vous remplacer "fichiers binaires propriétaires" par "fichiers d'archive avec en-têtes non standard ajoutés".
Ryan Thompson

Les personnes intéressées peuvent trouver un rpm2cpio.shscript.
Michael Shigorin

5

OpenSUSE Build Service (OBS) et zypper sont quelques-unes des raisons pour lesquelles je préfère RPM à deb du point de vue du conditionneur et de l'utilisateur. Zypper a parcouru un long chemin et est assez rapide. OBS, bien qu’il puisse gérer les debs, est vraiment sympa quand il s’agit d’emballer des rpms pour diverses plates-formes telles que openSUSE, SLE, RHEL, centos, fedora, mandriva, etc.


IMHO, le service de compilation openSUSE est la solution la plus intéressante qui soit. Ils ont vraiment bien fait les choses.
Archie

Bien qu’il s’agisse de deb vs rpm, vous avez raison. Zypper est génial avec la prise en charge des référentiels avec des priorités, ainsi que l’impressionnant solveur SAT.
décembre

5

Les paquets Debian peuvent inclure une taille installée , mais je ne pense pas que les RPM aient un champ équivalent. Il peut être calculé en fonction des fichiers inclus dans le package, mais ne peut pas non plus être utilisé en raison d’actions pouvant être effectuées dans les scripts de pré / post-installation.

Voici une assez bonne référence pour comparer certaines fonctionnalités spécifiques disponibles pour chaque format de packaging spécifique: http://debian-br.sourceforge.net/txt/alien.htm (selon le serveur Web, ce document est relativement ancien : dernière mise à jour: Sun, 15 octobre 2000 donc cela pourrait ne pas être la meilleure référence).


1
Bonjour @ MikeGray. Le lien est cassé. S'il vous plaît pourriez-vous le mettre à jour?
olibre

4

Pour les paquets Debian, il existe un grand nombre de scripts d’aide, un manuel de politique cohérent et au moins une façon de faire presque tout. Les dépendances sont très bien gérées et peuvent être définies avec une très bonne granularité. La reconstruction des paquets est très facile avec les paquets Debian et bien supportée par les outils disponibles.


Toutes ces choses sont également vraies pour, par exemple, les RPM emballés pour Fedora.
Mattdm

1
Les outils de génération de dépendances de Debian sont presque inexistants, nous avons une petite avance sur ALT Linux (distribution basée sur RPM utilisant APT).
Michael Shigorin

4

Aucune des autres réponses n'indique en quoi les trois différences fondamentales suivantes ont des conséquences réelles:

  1. debles fichiers sont essentiellement des ararchives contenant deux archives compressées
  2. debles paquets et le dpkgsystème stockent vos scripts de responsable en tant que fichiers séparés
  3. dpkget rpmexécutez les scripts du responsable dans un ordre différent lors des mises à niveau.

Ensemble, ces différences ont beaucoup facilité la résolution des problèmes causés par les mauvais paquets et le fait que les paquets se comportent comme je le souhaite, debsystèmes sur rpmbase plutôt que systèmes sur base, à la fois en tant qu'administrateur système et en tant qu'emballeur .

En raison de la position n ° 1, si je dois modifier un debfichier, je peux l’ouvrir, y apporter les modifications souhaitées et le reconditionner à l’ aide des outils standard de la plupart des systèmes .

Cela inclut la modification / l'ajout / la suppression de dépendances, de l'un des fichiers de package ou de l'un des scripts du responsable, ou la modification de la version ou du nom du package.

En raison de # 2, s'il y a un problème dans les scripts "remove" installés par un paquet déjà installé , je peux le réparer de manière simple , en utilisant les outils standard existants sur tous les systèmes .

En raison de # 3, je peux faire certaines de ces corrections simplement en libérant une nouvelle version de mon paquet, parce que pendant la mise à niveau, dpkgexécute le script « pré-installation » de la nouvelle version du package avant le script « post-remove » de l'ancienne version.

Cela signifie que la superficie pour violer le "principe de récupérabilité" est plus petite dans les debpackages: davantage d'erreurs dans une version antérieure du package peuvent être récupérées avec une nouvelle version.

Et comme la modification du paquet est si facile (les tâches de fauchage et de connaissances spécifiques à un paquet sont minimes), elles sont accessibles à plus de personnes et nécessitent moins de temps et d’efforts, avec des debfichiers.


Venant d'un arrière-plan principalement Red Hat, cette réponse est pour moi un regard merveilleux sur un nouveau monde. J'utilise maintenant Ubuntu à la maison, alors je suis impatient de pouvoir "jouer du violon" comme ça. La réponse serait améliorée, OMI, avec un lien vers une introduction à certains de ces "outils standard existants sur la plupart des systèmes" auxquels vous faites allusion. ;)
Wildcard il y a
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.