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

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?

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.

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.

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.

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).

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).

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.

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.

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.

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.

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).

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.

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.