Was sind die Vor- / Nachteile von deb gegenüber rpm?

Aus welchen Gründen auch immer, ich habe immer RPM-basierte Distributionen verwendet (Fedora, Centos und derzeit openSUSE). Ich habe oft gehört, dass deb besser ist als rpm, aber wenn ich gefragt werde, warum, habe ich nie eine kohärente Antwort bekommen (normalerweise bekomme ich stattdessen ein paar eifrige Scherze und reichliche Mengen an Spucke).

Ich verstehe, dass es einige historische Gründe geben kann, aber kann bei modernen Distributionen, bei denen zwei verschiedene Verpackungsmethoden verwendet werden, jemand die technischen (oder sonstigen) Vorzüge des einen gegenüber dem anderen angeben?

Der Hauptunterschied für einen Paketbetreuer (ich denke, das wäre 'Entwickler' in Debian-Jargon) ist die Art und Weise, wie Paket-Metadaten und zugehörige Skripte zusammenkommen.

In der RPM-Welt befinden sich alle Ihre Pakete (die von Ihnen verwalteten RPMs) in etwa ~/rpmbuild. Darunter befinden sich das SPECVerzeichnis für Ihre Spezifikationsdateien, ein SOURCESVerzeichnis für Quell-Tarballs RPMSund SRPMSVerzeichnisse, in denen neu erstellte RPMs und SRPMs abgelegt werden können, sowie einige andere Dinge, die derzeit nicht relevant sind.

Alles , was damit zu tun hat, wie das RPM erstellt wird, befindet sich in der Spezifikationsdatei: Welche Patches werden angewendet, mögliche Pre- und Post-Skripte, Metadaten, Changelog, alles. Alle Quell-Tarballs und alle Patches aller Ihrer Pakete befinden sich in SOURCES.

Nun persönlich mag ich die Tatsache, dass alles in die Spezifikationsdatei aufgenommen wird und dass die Spezifikationsdatei eine vom Quell-Tarball getrennte Entität ist, aber ich bin nicht übermäßig begeistert, alle Quellen in SOURCES zu haben. IMHO, SOURCES wird ziemlich schnell überfüllt und Sie neigen dazu, den Überblick darüber zu verlieren, was sich dort befindet. Die Meinungen sind jedoch unterschiedlich.

Für RPMs ist es wichtig , dass bis zum Zeitstempel genau derselbe Tarball verwendet wird, den das vorgelagerte Projekt veröffentlicht. Im Allgemeinen gibt es keine Ausnahmen von dieser Regel. Debian-Pakete erfordern auch dasselbe Tarball wie Upstream, obwohl nach Debian-Richtlinien einige Tarballs neu gepackt werden müssen (danke, Umang).

Debian-Pakete verfolgen einen anderen Ansatz. (Verzeihen Sie hier alle Fehler: Ich habe viel weniger Erfahrung mit Debs als mit RPMs.) Die Entwicklungsdateien von Debian-Paketen sind in einem Verzeichnis pro Paket enthalten.

Was mir an diesem Ansatz gefällt, ist die Tatsache, dass alles in einem einzigen Verzeichnis enthalten ist.

In der Debian-Welt ist es ein bisschen akzeptierter, Patches in einem Paket zu haben, das (noch) nicht upstream ist. In der RPM-Welt (zumindest bei den Red Hat-Derivaten) ist dies verpönt. Siehe "FedoraProject: In der Nähe von vorgelagerten Projekten bleiben" .

Außerdem verfügt Debian über eine Vielzahl von Skripten, mit denen ein großer Teil der Paketerstellung automatisiert werden kann. Zum Beispiel ist das Erstellen eines - einfachen - Pakets eines mit setuptool erstellten Python-Programms so einfach wie das Erstellen und Ausführen einiger Metadatendateien debuild. Das heißt, die Spezifikationsdatei für ein solches Paket im RPM-Format wäre ziemlich kurz und auch in der RPM-Welt gibt es eine Menge Dinge, die heutzutage automatisiert werden.

Viele Leute vergleichen die Installation von Software mit apt-getzu rpm -i, und deshalb sagen DEB besser. Dies hat jedoch nichts mit dem DEB-Dateiformat zu tun. Der echte Vergleich ist dpkgvs rpmund aptitude/ apt-*vs zypper/ yum.

Aus Sicht des Benutzers gibt es bei diesen Tools keinen großen Unterschied. Bei den Formaten RPM und DEB handelt es sich nur um Archivdateien, an die einige Metadaten angehängt sind. Sie sind beide gleichermaßen geheimnisvoll, haben fest codierte Installationspfade (yuck!) Und unterscheiden sich nur in subtilen Details. Beide dpkg -iund rpm -ihaben keine Möglichkeit, herauszufinden, wie Abhängigkeiten installiert werden, es sei denn, sie werden zufällig in der Befehlszeile angegeben.

Zusätzlich zu diesen Tools gibt es eine Repository-Verwaltung in Form von apt-...oder zypper/ yum. Diese Tools laden Repositorys herunter, verfolgen alle Metadaten und automatisieren das Herunterladen von Abhängigkeiten. Die endgültige Installation jedes einzelnen Pakets wird an die Low-Level-Tools übergeben.

Lange Zeit war apt-getes überlegen, die enorme Menge an Metadaten wirklich schnell zu verarbeiten, während es yumewig dauern würde, es zu tun. RPM litt auch unter Sites wie rpmfind, auf denen Sie über 10 inkompatible Pakete für verschiedene Distributionen finden würden. AptDieses Problem wurde für DEB-Pakete vollständig ausgeblendet, da alle Pakete von derselben Quelle installiert wurden.

Meiner Meinung nach zypperhat sich diese Lücke wirklich geschlossen aptund es gibt keinen Grund, sich heutzutage für die Verwendung einer RPM-basierten Distribution zu schämen. Es ist genauso gut, wenn nicht einfacher, es mit dem verfügbaren openSUSE-Build-Service für einen riesigen kompatiblen Paketindex zu verwenden.

Aus der Sicht eines Systemadministrators habe ich ein paar kleinere Unterschiede festgestellt, hauptsächlich im dpkg / rpm-Toolset und nicht im Paketformat.

• dpkg-divertErmöglicht, dass Ihre eigene Datei die aus einem Paket stammende Datei ersetzt. Dies kann lebensrettend sein, wenn Sie ein Programm haben, das nach einer Datei in /usroder sucht /libund keine /usr/localAntwort erwartet . Die Idee wurde vorgeschlagen, aber soweit ich das beurteilen kann nicht übernommen, in rpm.

• Wenn ich RPM-basierte Systeme zuletzt verwaltet habe (was zugegebenermaßen vor Jahren der Fall war, hat sich die Situation möglicherweise verbessert), hat *.rpmsaveRPM immer geänderte Konfigurationsdateien überschrieben und meine Anpassungen in (IIRC) verschoben. Dies hat mein System mindestens einmal nicht mehr bootfähig gemacht. Dpkg fragt mich, was ich tun soll, wobei meine Anpassungen als Standard beibehalten werden.

• Ein rpm-Binärpaket kann Abhängigkeiten von Dateien anstelle von Paketen deklarieren, was eine genauere Steuerung ermöglicht als ein deb-Paket.

• Sie können ein RPM-Paket der Version N nicht auf einem System mit Version N-1 der RPM-Tools installieren. Das könnte auch für dpkg gelten, außer dass sich das Format nicht so oft ändert.

• Die dpkg-Datenbank besteht aus Textdateien. Die rpm-Datenbank ist binär. Dadurch ist die dpkg-Datenbank leicht zu untersuchen und zu reparieren. Auf der anderen Seite kann die Drehzahl, solange nichts schief geht, viel schneller sein (für die Installation einer Deb müssen Tausende kleiner Dateien gelesen werden).

• Ein deb - Paket verwendet Standardformate ( ar, tar, gzip) , so können Sie überprüfen, und in einer Prise zwicken) deb - Pakete leicht. RPM-Pakete sind bei weitem nicht so freundlich.

RPM:

• 'Standardisiert' (nicht, dass es keine Deb-Spezifikation gibt)
• Wird von vielen verschiedenen Distributionen verwendet (Pakete von einer funktionieren jedoch nicht unbedingt auf einer anderen)
• IIRC erlaubt Abhängigkeiten von Dateien, nicht nur von Paketen

DEB:

• Wachsende Popularität
• Ermöglicht Empfehlungen und Vorschläge (möglicherweise erlaubt es auch ein neueres RPM)

Die wahrscheinlich wichtigere Frage ist der Paketmanager (dpkg vs. yum vs. aptitude usw.) und nicht das Paketformat (da beide vergleichbar sind).

Da mehrere Responder gesagt, es ist nicht so sehr , dass ein bestimmtes Paket - Format deutlich überlegen ist. Technisch können sie mehr oder weniger vergleichbar sein. Aus meiner Sicht haben viele der Unterschiede, und warum Menschen einander vorziehen, damit zu tun:

• Die Philosophie des Originalverpackungsdesigns und der Zielgruppe
• Die Community-Größe und damit auch die Qualität und der Reichtum der Repositorys

Philosophie:

In der Welt von Ubuntu / Debian / Mint / ... erwarten Benutzer, dass das installierte Paket "nur funktioniert", wenn es installiert ist. Dies bedeutet, dass die Pakete während der Installation alles erledigen müssen, damit sie auch tatsächlich funktionieren, einschließlich, aber nicht beschränkt auf:

• benötigte oder optionale Cronjobs einrichten
• Einrichten von Alternativen / Aliasen
• Einrichten von Start / Shutdown-Skripten
• Einschließlich aller erforderlichen Konfigurationsdateien mit sinnvollen Standardeinstellungen
• Beibehaltung alter Versionen von Bibliotheken und Hinzufügen der richtigen versionierten Symlinks zu Bibliotheken (.so) aus Gründen der Abwärtskompatibilität
• saubere Unterstützung für Multi-Arch-Binärdateien (32 und 64 Bit) auf demselben Computer und so weiter.

In der RPM-Welt - zugegebenermaßen war dies vor einigen Jahren der Fall und es hat sich seitdem möglicherweise verbessert - musste ich zusätzliche Schritte ausführen (z. B. chkconfig, das Aktivieren von Cron-Jobs), damit Pakete tatsächlich funktionieren. Dies mag für Sysadmins oder Leute, die sich mit Unix auskennen, in Ordnung sein, aber Anfänger leiden darunter. Beachten Sie, dass dies nicht durch das RPM-Paketformat selbst verhindert wird, sondern dass viele Pakete aus der Sicht eines Neulings de facto nicht "vollständig" erstellt wurden .

Community-Größe, Beteiligung und Reichtum an Repositories:

Da die ubuntu / debian / mint / ... - Community größer ist, sind mehr Menschen in das Packen und Testen von Software involviert. Ich fand den Reichtum und die Qualität der Repositories überlegen. In Ubuntu muss ich selten, wenn überhaupt, den Quellcode herunterladen und daraus erstellen. Als ich zu Hause von Red Hat auf Ubuntu umgestiegen bin, enthielt das typische RHEL-Repo ~ 3000 Pakete, während Ubuntu + Universum + Multiversum, alle direkt von einem Canonical-Spiegel verfügbar, ~ 30.000 Pakete enthielt (ungefähr 10x). Die meisten Pakete, die ich im RPM-Format suchte, waren nicht über eine einfache Suche und einen Klick im Paketmanager verfügbar. Sie mussten zu alternativen Repositories wechseln, die rpmfind-Service-Website durchsuchen usw. Dies löste in den meisten Fällen das Problem, anstatt es zu lösen. hat meine Installation abgebrochen, weil ich nicht eingeschränkt habe, welche Abhängigkeiten korrekt aktualisiert werden können oder nicht. Ich bin auf das Phänomen der "Abhängigkeitshölle" gestoßen, wie oben von Shawn J. Goff beschrieben.

Im Gegensatz dazu stellte ich in Ubuntu / Debian fest, dass ich fast nie aus dem Quellcode bauen muss. Auch wegen:

• Der Ubuntu Fast (6 Monate) Release-Zyklus
• Die Existenz voll kompatibler PPAs, die sofort einsatzbereit sind
• Die Single-Source-Repositories (alle von Canonical gehostet) müssen nicht nach alternativen / komplementären Repositories suchen
• Nahtlose Benutzererfahrung von Klick zu Klick

Ich musste nie Kompromisse bei älteren Versionen von Paketen eingehen, die mir wichtig waren, auch wenn sie nicht von offiziellen (Canonical) Entwicklern gepflegt wurden. Ich musste meinen bevorzugten freundlichen GUI-Paketmanager nie verlassen, um eine bequeme Suche nach Schlüsselwörtern durchzuführen und jedes gewünschte Paket zu finden und zu installieren. Außerdem habe ich einige Male debian (nicht Canonical) -Pakete auf Ubuntu installiert und sie funktionierten einwandfrei, obwohl diese Kompatibilität nicht offiziell garantiert wurde.

Beachten Sie, dass dies nicht dazu gedacht ist, einen Flammenkrieg auszulösen, sondern lediglich meine Erfahrung zu teilen, beide Welten mehrere Jahre lang parallel genutzt zu haben (Arbeit gegen Zuhause).

Ich denke, dass die Verzerrung nicht vom Paketformat herrührt, sondern von den Inkonsistenzen, die früher in den Repositorys von RedHat bestanden.

Früher, als RedHat eine Distribution war (vor den Tagen von RHEL, Fedora und Fedora Core), befanden sich die Leute manchmal in der "RPM-Hölle" oder "Abhängigkeitshölle". Dies geschah, wenn ein Repository ein Paket mit Abhängigkeiten aufwies (normalerweise mehrere Ebenen tief), die sich gegenseitig ausschlossen. Oder es würde entstehen, wenn zwei verschiedene Pakete zwei sich gegenseitig ausschließende Abhängigkeiten hätten. Dies war ein Problem mit dem Status des Repositorys, nicht mit dem Paketformat. Die "RPM-Hölle" hinterließ bei einigen Linux-Anwendern, die sich durch das Problem verbrannt hatten, eine Abneigung gegen RPM-Systeme.

Es gibt auch den "philosophischen" Unterschied, wo Sie in Debian-Paketen Fragen stellen und dadurch den Installationsprozess blockieren können. Die schlechte Seite dabei ist, dass einige Pakete Ihre Upgrades blockieren, bis Sie antworten. Das Gute daran ist auch, dass auf Debian-basierten Systemen, wenn ein Paket installiert ist, es konfiguriert ist (nicht immer so, wie Sie es möchten) und ausgeführt wird. Nicht auf Redhat-basierten Systemen, auf denen Sie aus / usr / share / doc / * eine Standard- / Vorlagen-Konfigurationsdatei erstellen / kopieren müssen.

Eine Sache, die ich an RPMs mag, ist das (aktuelle?) Hinzufügen von Delta-RPMs. Dies erleichtert die Aktualisierung und reduziert die erforderliche Bandbreite.

DEBs sind Standard-AR-Dateien (mit mehr Standard-Archiven), RPMs sind "proprietäre" Binärdateien. Ich persönlich finde das erstere praktischer.

Nur zwei Dinge, die ich mir vorstellen kann. Beide sind sehr vergleichbar. Beide haben hervorragende Werkzeuge für die Verpackung. Ich glaube nicht, dass es so viele Vorteile gibt.

Der openSUSE Build Service (OBS) und zypper sind einige der Gründe, aus denen ich RPM aus Sicht des Packagers und des Benutzers gegenüber deb bevorzuge. Zypper hat einen langen Weg hinter sich und ist ziemlich blöd. Obwohl OBS Debs verarbeiten kann, ist es wirklich nett, RPMs für verschiedene Plattformen wie openSUSE, SLE, RHEL, Centos, Fedora, Mandriva usw. zu verpacken.

Debian-Pakete können eine installierte Größe enthalten , aber ich glaube nicht, dass RPMs ein gleichwertiges Feld haben. Es kann auf der Grundlage der im Paket enthaltenen Dateien berechnet werden, es kann jedoch auch nicht auf die Aktionen zurückgegriffen werden, die in den Pre / Post-Installationsskripten ausgeführt werden können.

Hier ist eine ziemlich gute Referenz zum Vergleich einiger spezifischer Funktionen, die für jedes spezifische Paketformat verfügbar sind: http://debian-br.sourceforge.net/txt/alien.htm (laut dem Webserver ist dieses Dokument ziemlich alt : Zuletzt geändert: So, 15. Oktober 2000. Dies ist möglicherweise nicht die beste Referenz.)

Für Debian-Pakete gibt es eine große Anzahl von Hilfsskripten, ein konsistentes Richtlinienhandbuch und mindestens eine Möglichkeit, fast alles zu tun. Abhängigkeiten werden sehr gut gehandhabt und können in sehr guter Granularität definiert werden. Das Neuerstellen von Paketen ist mit Debian-Paketen sehr einfach und wird von den verfügbaren Tools gut unterstützt.

Keine der anderen Antworten geht darauf ein, wie die folgenden drei fundamentalen Unterschiede echte Konsequenzen haben:

1. debDateien sind im Grunde genommen nur arArchive, die zwei komprimierte Tarballs enthalten
2. debPakete und das dpkgSystem speichern Ihre Betreuerskripte als separate Dateien
3. dpkgund rpmführen Sie die Betreuer-Skripte bei Upgrades in einer anderen Reihenfolge aus.

Zusammen haben diese Unterschiede machen es viel einfacher für mich durch schlechte Pakete verursachten Probleme zu beheben, und zu Paketen den Weg zu machen verhalten wir sie, auf benötigen deb-basierte Systeme als auf rpm-basierte Systemen, sowohl als Systemadministrator und als Verpacker .

Aufgrund von # 1 kann ich eine debDatei , wenn ich sie ändern muss , einfach öffnen, alle gewünschten Änderungen vornehmen und sie mit den auf den meisten Systemen vorhandenen Standardtools neu packen .

Dies umfasst das Ändern / Hinzufügen / Entfernen von Abhängigkeiten, Paketdateien oder Betreuerskripten sowie das Ändern der Paketversion oder des Paketnamens.

Aufgrund von # 2 kann ich ein Problem mit den von einem bereits installierten Paket installierten "remove" -Skripten mithilfe von Standardtools, die auf einem beliebigen System vorhanden sind, problemlos beheben .

Aufgrund von # 3 kann ich einige dieser Korrekturen einfach durch die Veröffentlichung einer neuen Version meines Pakets durchführen, da während des Upgrades dpkgdas Skript "Pre-Install" der neuen Version des Pakets vor dem Skript "Post-Remove" von ausgeführt wird die alte Version.

Dies bedeutet, dass die Oberfläche für die Verletzung des "Wiederherstellungsprinzips" in debPaketen kleiner ist : Mit einer neuen Version können mehr Fehler in einer früheren Version des Pakets behoben werden.

Und da das Ändern des Pakets so einfach ist - der eigentliche paketspezifische Aufwand für Fummelei und Wissen ist winzig -, können mehr Benutzer darauf zugreifen, und der Zeit- und Arbeitsaufwand für das debSpeichern von Dateien ist geringer .