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

171

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?

Evan
quelle

Antworten:

86

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.

wzzrd
quelle
9
Um Sie bei Debian-Paketen zu korrigieren, debianexistiert das Verzeichnis in dem Verzeichnis, in das die Upstream-Quelle extrahiert wurde, und Debian schätzt das Konzept eines unberührten Upstream-Quell-Tarballs sehr. Wenn ein Quellpaket erstellt wird, gibt es drei (zwei für native Pakete) Dateien, die zusammen als Quellpaket bezeichnet werden: Das Upstream-Tarball (vorzugsweise makellos, für Debian-Richtlinien müssen einige Projekte neu gepackt werden), ein Tarball des Debian-Verzeichnisses für das neues 3.0-Format (ein Unterschied zum alten 1.0-Format) und eine .dsc-Datei.
Umang
8
Das Debian-Verzeichnis geht nicht in den Upstream-Tarball, sondern verbleibt in den .diff.gzoder den .debian.tar.gzDateien des Quellpakets, obwohl sich das debianVerzeichnis innerhalb des Quellbaums befindet, wenn das Quellpaket extrahiert wird. Übrigens: Wenn die Richtlinie kein erneutes Packen erfordert, muss das MD5 des Tarballs mit dem des Upstream-Tarballs übereinstimmen. Um dies zu verdeutlichen, wurden Patches, die ich als Betreuer für den Upstream-Quellcode festgelegt habe, im Debian-Verzeichnis (Quellformat 3.0) und im .diff.gzFormat (1.0) gespeichert.
Umang
Umang, danke für deine Korrektur. Ich werde den Teil über das Ändern des Upstream-Tarballs streichen, um sicherzustellen, dass niemand die falsche Idee hat.
wzzrd
2
Sieht jetzt gut aus, außer dass Sie immer noch ein "Für RPMs ist es wichtig, dass Sie genau den gleichen Tarball wie den verwenden, den das vorgelagerte Projekt veröffentlicht, bis zum Zeitstempel." Aufgrund meiner mangelnden Erfahrung mit RPMs weiß ich nicht, ob der Unterschied in den Richtlinien groß ist, aber wie gesagt, ein Debian-Entwickler wird darauf bestehen, dass er genau zum Zeitstempel passt, es sei denn, der Upstream-Tarball verstößt gegen die Debian-Richtlinien und muss dies tun umgepackt werden.
Umang
7
@wzzrd, es ist eigentlich ganz einfach, Ihre Quelldateien in einem Paketverzeichnis zusammenzustellen, indem Sie% _specdir und% _sourcedir in Ihrer ~ / .rpmmacros-Datei definieren.
mattdm
94

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.

vdboor
quelle
@ Tshepang: behoben
vdboor
12
Meiner Meinung nach habe ich RPMs aus genau dem Grund verachtet, den Sie erwähnt haben: "RPM litt auch unter Websites wie rpmfind, auf denen Sie über 10 inkompatible Pakete für verschiedene Distributionen finden würden." Außerdem finde ich es äußerst schwierig, eine Drehzahl für die benötigte Software zu finden. Während für DEB: "Apt hat dieses Problem für DEB-Pakete vollständig ausgeblendet, da alle Pakete von derselben Quelle installiert wurden." die sind wirklich leicht zu finden und zu verwenden. Außerdem scheint DEB Abhängigkeiten immer besser zu finden und zu installieren, während RPMs mich immer hängen zu lassen schienen ... meine Meinung nach nach 15 Jahren mit beiden!
Jeach
2
Ich glaube, diese Antwort befasst sich mit der Frage aus Verbrauchersicht, im Gegensatz zu @ wzzrd's, das vollständig auf Entwickler / Paketierer ausgerichtet ist. Auch sehr klar über die Ebenentrennung.
GnP
1
Dein Text wurde in WikiVS kopiert , scheint richtig zugeordnet zu sein.
Martin Ueding
1
Aus Benutzersicht ist dies die beste Antwort. Und ich würde hinzufügen, dass die Verwendung von PPAs viel einfacher ist als das Hinzufügen eines neuen Yum Repo.
Marco Sulla
39

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.

Gilles
quelle
2
Es sieht so aus, als würde heutzutage die neue Konfigurationsdatei gespeichert, *.rpmnewanstatt die geänderte zu löschen - zumindest unter openSUSE.
Evan
1
Beides ist erledigt, so dass Sie eine Streuung von RPMSave- und RPM-neuen Dateien erhalten.
Burhan Ali
4
Sie sind falsch über RPMs verwenden keine Standardformate. RPMS verwenden CPIO für den Datenabschnitt, der ein Standardarchivformat ist. Die anderen Abschnitte sind meist Überschriften. Sie können das Tool rpm2cpio verwenden, um nur den Datenabschnitt des RPM zu extrahieren und die in dem RPM enthaltenen Dateien zu extrahieren. Zum Beispiel: rpm2cpio foobar.rpm | cpio -idmv
Tuxdude
... und es gibt rpm2cpio.shfür die geneigten.
Michael Shigorin
Die einzige bahnbrechende Änderung des debFormats , an die ich mich erinnere, war, wann es data.tar.gzwurde data.tar.xzund zu welchem ​​Zeitpunkt ältere nicht dpkgmehr in der Lage waren, neue Pakete zu öffnen.
mtraceur
19

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

Maciej Piechotka
quelle
6
Ist "wachsende Popularität" nicht im Grunde genommen "Ubuntu basiert auf Debian und so, weißt du, geht es?"
mattdm
„dpkg vs yum“ ist der falsche Vergleich als die früheren ist ein Paket - Manager aber diese sind nicht (wie apt / aptitude ist Repository Level - Manager und nicht nur „Paket“).
Michael Shigorin
13

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

Arielf
quelle
Es geht eher um "redhat vs canonical" (mit canonical, was Debian seit zwei Jahrzehnten macht) und nicht um "rpm vs deb" - das sage ich als Mitglied des ALT Linux-Teams.
Michael Shigorin
Ja genau. Und gut gesagt.
Arielf
12

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.

Shawn J. Goff
quelle
8

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.

Luc Stepniewski
quelle
6

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.

Johansson
quelle
7
RPMs als "proprietär" zu bezeichnen, ist etwas schwierig. Es gibt einige zusätzliche Header und dergleichen, aber der Kern eines RPM ist ein mit gzip komprimiertes cpio-Archiv. Es gibt ein Tool namens rpm2cpio, mit dem Sie diesen Kern extrahieren können, damit Sie damit spielen können, wie Sie es mit einer .deb-Datei tun können.
Warren Young
4
Müll. RPMs sind keine proprietären Binärdateien. Sie basierten auf cpio (das ist zwar alt, aber nicht proprietär), während neuere RPM-Versionen xz verwenden, das auch als Open Source verfügbar ist.
Wzzrd
Richtig, ich habe es zitiert, weil es natürlich nicht wirklich proprietär ist und genau das meine ich: zusätzliche Header usw. Es ist also keine reine Datei wie ein Deb. Keine große Sache, nur eine Kleinigkeit.
Johansson
5
Vielleicht sollten Sie "proprietäre Binärdateien" durch "Archivdateien mit nicht standardmäßigen Headern" ersetzen.
Ryan Thompson
Interessenten finden rpm2cpio.shSkript.
Michael Shigorin
5

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.

Beschreiber
quelle
Meiner Meinung nach ist der openSUSE-Build-Service das Coolste, was es seit langem gibt. Sie haben es wirklich richtig gemacht.
Archie
Obwohl es um Deb vs. RPM geht, haben Sie Recht. Zypper ist großartig, wenn es darum geht, Repositories mit Prioritäten und den großartigen SAT-Solver zu unterstützen.
Drahnr
5

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

Mike Gray
quelle
1
Hi @MikeGray. Die Verbindung ist unterbrochen. Könnten Sie es bitte aktualisieren?
Olibre
4

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.

tex
quelle
All dies gilt zum Beispiel auch für RPMs, die für Fedora gepackt wurden.
Mattdm
1
Debians Tools zur Generierung von Abhängigkeiten sind so gut wie nicht vorhanden, wir sind in ALT Linux (RPM-basierte Distribution mit APT) nur ein paar Jahre voraus.
Michael Shigorin
3

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 .

mtraceur
quelle