Quels sont les avantages / inconvénients de deb vs rpm?
Pour quelque raison que ce soit, 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 m'a demandé pourquoi, je n'ai jamais pu obtenir une réponse cohérente (obtenez généralement des diatribes zélées et des quantités copieuses de crachats à la place).
Je comprends qu'il peut y avoir des raisons historiques, mais pour les distributions modernes utilisant les deux méthodes de conditionnement différentes, quelqu'un peut-il donner les mérites techniques (ou autres) de l'un par rapport à l'autre?
La principale différence pour un mainteneur de paquet (je pense que ce serait "développeur" dans le jargon Debian) est la façon dont les métadonnées du paquet et les scripts qui les accompagnent se rejoignent.
Dans le monde des RPM, tous vos packages (les RPM que vous gérez) se trouvent dans quelque chose comme ~/rpmbuild. En dessous, il y a le répertoire SPEC pour vos fichiers de spécifications, un répertoire SOURCES pour les archives tar source, RPMS et SRPMS pour mettre les RPM nouvellement créés et SRPM dans, et d'autres choses qui ne sont pas pertinentes maintenant.
Tout qui a à voir avec la façon dont le RPM sera créé se trouve dans le fichier de spécifications: quels correctifs seront appliqués, pré- et post-scripts possibles , métadonnées, changelog, tout. Toutes les archives tar et tous les correctifs de tous vos packages sont dans SOURCES.
Maintenant, personnellement, j'aime le fait que tout va dans le fichier de spécifications et que le fichier de spécifications est une entité distincte de l'archive tar source, mais je ne suis pas trop enthousiaste à l'idée d'avoir toutes les sources dans SOURCES. À mon humble avis, les sources s'encombrent assez rapidement et vous avez tendance à perdre la trace de ce qui s'y trouve. Cependant, les opinions divergent.
Pour les RPM, il est important d'utiliser ( exactement le même tarball que celui publié par le projet en amont, jusqu'à l'horodatage). En règle générale, il n'y a aucune exception à cette règle. Les paquets Debian nécessitent également le même tarball qu'en amont, bien que la politique Debian nécessite le reconditionnement de certains tarballs (merci, Umang).
Les paquets Debian ont une approche différente. (Pardonnez toute erreur ici: je suis beaucoup moins expérimenté avec deb qu'avec les 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, c'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 ne sont pas (encore) en amont. Dans le monde RPM (au moins parmi les dérivés de Red Hat), cela est mal vu. Voir "FedoraProject: rester proche des projets en amont" .
De plus, Debian possède une grande quantité de scripts capables d'automatiser une grande partie de la création d'un paquet. Par exemple, créer un package - simple - d'un setuptool'ed Python, est aussi simple que de créer quelques fichiers de métadonnées et d'exécuter debuild. Cela dit, le fichier de spécifications pour un tel paquet au format RPM serait assez court et dans le monde RPM aussi, il y a beaucoup de choses qui sont automatisées de nos jours.
Beaucoup de gens comparent l'installation de logiciels avec apt-get à rpm -i, et donc mieux dire DEB. Cela n'a cependant rien à voir avec le format de fichier DEB. La vraie comparaison est dpkg vs rpm et aptitude/apt-* vs zypper/yum.
Du point de vue d'un utilisateur, il n'y a pas beaucoup de différence dans ces outils. Les formats RPM et DEB ne sont que des fichiers d'archive, avec des métadonnées attachées. Ils sont tous deux également obscurs, ont des chemins d'installation codés en dur (beurk!) Et ne diffèrent que par des détails subtils. Tous les deux dpkg -i et rpm -i n'a aucun moyen de comprendre comment installer les 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, apt-get a été supérieur dans le traitement de l'énorme quantité de métadonnées très rapidement tandis que yum mettrait du temps à le faire. RPM a également souffert de sites comme rpmfind où vous trouverez plus de 10 packages incompatibles pour différentes distributions. Apt a complètement masqué ce problème pour les packages DEB car tous les packages ont été installés à partir de la même source.
À mon avis, zypper a vraiment comblé l'écart avec apt et il n'y a aucune raison d'avoir honte d'utiliser une distribution basée sur RPM de nos jours. C'est tout aussi bien sinon plus facile à utiliser avec le service de construction openSUSE à portée de main pour un énorme index de paquet compatible.
Du point de vue d'un administrateur système, j'ai trouvé quelques différences mineures, principalement dans l'ensemble d'outils dpkg/rpm plutôt que dans le format du package.
dpkg-divertpermet d'avoir votre propre fichier en remplacement de celui provenant d'un package. Cela peut vous sauver la vie lorsque vous avez un programme qui recherche un fichier dans/usrou/libet ne prendra pas/usr/localpour une réponse. L'idée a été proposée, mais pour autant que je sache, elle n'a pas été adoptée, en rpm.Lors de la dernière administration de systèmes basés sur rpm (ce qui, il est vrai, 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 déplaçait mes personnalisations dans
*.rpmsave(IIRC). Cela a rendu mon système impossible à démarrer au moins une fois. Dpkg me demande quoi faire, 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 fin qu'un package deb.
Vous ne pouvez pas installer un package rpm version N sur un système avec la version N-1 des outils rpm. Cela peut également s'appliquer à dpkg, sauf que le format ne change pas aussi souvent.
La base de données dpkg se compose de fichiers texte. La base de données rpm est binaire. Cela facilite la recherche et la réparation de la base de données dpkg. D'un autre côté, tant que rien ne va mal, le rpm peut être beaucoup plus rapide (l'installation d'un deb nécessite la lecture de milliers de petits fichiers).
Un paquet deb utilise des formats standard (
ar,tar,gzip) afin que vous puissiez inspecter, et en un clin d'œil Tweak) les paquets deb facilement. Les packages RPM ne sont pas aussi conviviaux.
RPM:
- 'Standardisé' (pas qu'il n'y ait pas de spécification deb)
- Utilisé par de nombreuses distributions différentes (mais les packages de l'une ne fonctionnent pas nécessairement sur une autre)
- L'IIRC autorise les dépendances sur les fichiers, pas seulement sur les packages
DEB:
- Une popularité croissante
- Permet des recommandations et des suggestions (éventuellement un RPM 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 du package (car les deux sont comparables).
Comme l'ont dit plusieurs répondants, ce n'est pas tant qu'un certain format de package 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'un à l'autre, ont à voir avec:
- La philosophie de la conception originale de l'emballage et le public cible
- La taille de la communauté, et par extension, la qualité et la richesse des référentiels
Philosophie:
Dans le monde Ubuntu/Debian/Mint/..., les utilisateurs s'attendent à ce que le package installé "fonctionne juste" une fois qu'il est installé. Cela signifie que lors de l'installation, les packages sont censés prendre en charge tout le nécessaire pour qu'ils fonctionnent correctement, y compris mais sans s'y limiter:
- configuration des tâches cron nécessaires ou facultatives
- configuration d'alternatives/alias
- configuration des 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 bons liens symboliques versionnés aux bibliothèques (.so's) pour une compatibilité descendante
- support propre pour les binaires multi-Arch (32 et 64 bits) sur la même machine et ainsi de suite.
Dans le monde du RPM - il est vrai que c'était la situation il y a plusieurs années, et elle s'est peut-être améliorée depuis - je me suis retrouvé à devoir exécuter des étapes supplémentaires (par exemple chkconfig, activer les tâches cron) pour que les packages fonctionnent réellement. Cela peut convenir aux administrateurs système ou aux personnes connaissant bien Unix, mais cela fait souffrir les débutants. Notez que ce n'est pas que le format de package RPM lui-même empêche cela de se produire, c'est juste que de nombreux packages ne sont pas de facto "complètement terminés" de la perspective d'un débutant.
Taille de la communauté, participation et richesse des référentiels:
Étant donné que la communauté ubuntu/debian/mint/... est plus grande, plus de personnes sont impliquées dans le packaging et les tests de logiciels. J'ai trouvé la richesse et la qualité des référentiels supérieures. Dans Ubuntu, j'ai rarement, voire pas du tout, besoin de télécharger la source et de construire à partir de celle-ci. Lorsque je suis passé de Red Hat à Ubuntu à la maison, le référentiel RHEL typique contenait environ 3000 packages, tandis que dans le même temps, ubuntu + univers + multivers, tous disponibles directement à partir de n'importe quel miroir canonique, comptait environ 30000 packages (environ 10 fois). La plupart des packages que je cherchais au format RPM n'étaient pas facilement accessibles via une simple recherche et un clic dans le gestionnaire de packages. Ils ont dû passer à des référentiels alternatifs, rechercher le site Web du service rpmfind, etc. Cela, dans la plupart des cas, plutôt que de résoudre le problème, a interrompu mon installation en ne limitant pas les dépendances pouvant ou non être mises à niveau correctement. J'ai frappé le phénomène de "l'enfer de la dépendance", 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:
- Le cycle de publication rapide d'Ubuntu (6 mois)
- L'existence de PPA entièrement compatibles qui fonctionnent hors de la boîte
- Les référentiels à source unique (tous hébergés par Canonical) pas besoin de rechercher des référentiels alternatifs/complémentaires
- Expérience utilisateur transparente du clic pour exécuter
Je n'ai jamais eu à faire de compromis sur les anciennes versions de packages auxquels je tenais, même lorsqu'ils n'étaient pas maintenus par des développeurs officiels (canoniques). Je n'ai jamais eu à quitter mon gestionnaire de packages GUI amical préféré pour effectuer une recherche pratique par mot-clé, pour trouver et installer le package que je voulais. De plus, j'ai installé plusieurs fois des paquets Debian (non canoniques) sur Ubuntu et ils ont très bien fonctionné, bien que cette compatibilité ne soit pas officiellement garantie.
Notez que ce n'est pas destiné à déclencher une guerre des flammes, c'est juste partager mon expérience d'avoir utilisé les deux mondes en parallèle pendant plusieurs années (travail vs maison).
Je pense que le biais ne vient pas du format du package, mais des incohérences qui existaient auparavant dans les référentiels de RedHat.
À l'époque où RedHat était une distribution (avant l'époque de RHEL, Fedora et Fedora Core), les gens se retrouvaient parfois dans "RPM Hell" ou "dependency Hell". Cela s'est produit lorsqu'un référentiel se retrouvait avec un package qui avait des dépendances (plusieurs couches profondes, généralement) qui s'excluaient mutuellement. Ou cela surviendrait lorsque deux packages différents avaient deux dépendances mutuellement exclusives. Il s'agissait d'un problème avec l'état du référentiel, pas avec le format du package. Le "RPM Hell" a laissé un mauvais 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" où dans les paquets Debian vous pouvez poser des questions et par là, bloquer le processus d'installation. Le mauvais côté est que certains packages bloquent vos mises à niveau jusqu'à ce que vous répondiez. Le bon côté de cela est, également en tant que différence philosophique, sur les systèmes basés sur Debian, lorsqu'un paquet est installé, il est configuré (pas toujours comme vous le souhaitez) et fonctionne. 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/modèle.
Une chose que j'aime dans les RPM est l'ajout (récent?) De RPM delta. Cela permet une mise à jour plus facile, réduisant 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 du haut de ma tête. 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 l'un par rapport à l'autre ou vice versa.
Les paquets Debian peuvent inclure un taille installée , mais je ne pense pas que les RPM aient un champ équivalent. Il peut être calculé sur la base des fichiers inclus dans le package, mais ne peut pas non plus être utilisé en raison des actions qui peuvent être effectuées dans les scripts de pré/post-installation.
Voici une très bonne référence pour comparer certaines fonctionnalités spécifiques disponibles pour chaque format d'emballage spécifique: http://debian-br.sourceforge.net/txt/alien.htm (selon le web serveur, ce document est assez ancien: Dernière modification: dimanche 15 octobre 2000 donc ce n'est peut-être pas la meilleure référence.)
Le service de construction openSUSE (OBS) et zypper sont quelques-unes des raisons pour lesquelles je préfère RPM à deb d'un point de vue packager et 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 de créer des RPM pour diverses plates-formes telles que openSUSE, SLE, RHEL, centos, Fedora, mandriva, etc.
Aucune des autres réponses ne touche à la façon dont les trois différences fondamentales suivantes ont des conséquences réelles:
debles fichiers sont essentiellement des archivesarcontenant deux tarballs compressésdebpackages et le systèmedpkgstockent vos scripts de maintenance dans des fichiers séparésdpkgetrpmexécutent les scripts du responsable dans un ordre différent lors des mises à niveau.
Ensemble, ces différences ont rendu beaucoup plus facile pour moi de résoudre les problèmes causés par de mauvais paquets et de faire en sorte que les paquets se comportent comme j'en ai besoin, sur deb-based systems que sur rpm- based systems, both as a system administrator et en tant que conditionneur.
En raison de # 1, si je dois changer un fichier deb, je peux l'ouvrir de manière triviale, apporter les modifications que je souhaite et le reconditionner, en utilisant les outils standard qui existent sur la plupart des systèmes .
Cela inclut la modification/l'ajout/la suppression de toutes les dépendances, ou l'un des fichiers de package, ou 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 "supprimer" installés par un package qui est déjà installé , je peux le résoudre trivialement, en utilisant des outils standard qui existent sur n'importe quel système .
En raison de # 3, je peux faire certains de ces correctifs simplement en publiant une nouvelle version de mon package, car pendant la mise à niveau, dpkg exécute le script "pré-installation" de la nouvelle version du package avant le script "post-remove" de l'ancienne version.
Cela signifie que la surface pour violer le "principe de récupérabilité" est plus petite dans les packages deb: plus d'erreurs dans une version antérieure du package peuvent être récupérées avec une nouvelle version.
Et puisque la modification du package est si facile - le fiddling et les frais généraux de connaissances spécifiques au package sont minuscules - il est accessible à plus de personnes et prend moins de temps et d'efforts, avec les fichiers deb.
Pour les paquets Debian, il existe un large ensemble 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.
Allez chercher Google pour
- packages en double rpm
- packages en double dpkg
Lisez les pages qui reviennent. Très révélateur que vous pouvez avoir une base de données RPM foirée avec des packages en double alors qu'aucun cas de ce genre ne se produit avec dpkg.