Unterschiede in der Paketverwaltung zwischen Debian und Arch

9

Eine Diskussion in diesem Beitrag hat mich neugierig gemacht auf Unterschiede zwischen Debian und Arch-Paketverwaltung. Außerdem neigen die Leute dazu zu sagen, dass Arch sehr leicht ist, daher frage ich mich, was das mit der Paketverwaltung zu tun hat. Liegt es vielleicht daran, dass Debian Empfehlungen standardmäßig als harte Abhängigkeiten behandelt ?

Können Sie auch die Flexibilität / Leistung zwischen den beiden Paketmanagern erwähnen: Mit welchem ​​der beiden können Sie mehr tun?

Ich bin mir bewusst, dass einige Funktionen, die auf einem Debian-Paketverwaltungssystem verfügbar sind, auf einem Arch-System irrelevant sind, da Arch über eine einzelne Suite und Debian über mehrere Funktionen verfügt (z. B. APT-Pinning und erweiterte Abhängigkeitsbehandlung). Vergleichen Sie daher bitte die entsprechenden Funktionen sind auf beide Systeme anwendbar (dh ich nehme an, dass ich für Debian nur instabil verwende ).

Tshepang
quelle
HINWEIS : Bei der Debian-Paketverwaltung beziehe ich mich auf APT, aptitude und dpkg. Ich bin nicht mit Arch-Tools vertraut, daher weiß ich nicht, ob es etwas anderes als Pacman gibt.
Tshepang

Antworten:

7

Ich benutze arch seit einigen Wochen nur regelmäßig und bin kein Experte auf diesem Gebiet, daher ist diese Antwort keineswegs erschöpfend, nur ein paar Punkte, die ich über die "Flexibilität / Kraft" bemerkt habe:

  • Dies ist nur ein Eindruck, aber Pacman wirkt in seiner Gestaltung / Architektur moderner und einfacher. Zumindest gibt es weit weniger Werkzeuge, mit denen man umgehen muss. Obwohl ich keinen passenden Quellcode kenne, habe ich mir zufällig den libalpm-Code (die zugrunde liegende Bibliothek von pacman) angesehen, um einen sehr einfachen Patch zu erstellen, und er scheint sauber und leicht zu verstehen.

  • Es ist auch sehr schnell (aufgrund der Optimierung und wahrscheinlich auch, indem man sich um einige Dinge kümmert (siehe unten)). In der letzten Version (Pacman 3.5, einige Tage alt) wurde versucht, die Leistung zu verbessern, indem die Anzahl der beteiligten Datenbankdateien reduziert wurde.

  • Arch ist zwar auf die Verwendung von Binärpaketen ausgerichtet, bietet jedoch auch Vorteile beim Erstellen von Paketen aus dem Quellcode mit einem Build-System, das den BSD-Ports (ABS) ähnelt.

  • Es ist sehr einfach und schnell, Pakete zu erstellen, nur ein paar Zeilen in einer PKGBUILD-Datei und fertig. Sie müssen sich nicht mit Control / Rules / Copyright / Changelog / wie auch immer mit Debian-Paketen befassen. Und mit wenigen Klicks in einer Web-Benutzeroberfläche wird Ihr Paket für alle Benutzer von AUR (Arch User Repository) freigegeben.

Dinge, die ich in Debian und nicht in Arch bekomme:

  • Trigger / Hooks (was dazu führt, dass apt den Symbol-Cache, das Mandb oder was auch immer aktualisiert, indem man sich nur ansieht, wo das Paket die Dateien installiert, ohne dass der Packager etwas tun muss) (anscheinend gibt es Pläne , dies zu implementieren).

  • debconf (keine große Sache und zwingt mich übrigens dazu, Dinge manuell zu tun, zwingt es mich zu wissen, was genau getan wird) und den richtigen Umgang mit neuen Konfigurationsdateien (ich möchte zumindest, dass pacman weiß, wann eine Konfigurationsdatei in einem neuen Paket enthalten ist Die Version unterscheidet sich von der installierten Version, da sie in der neuen Version geändert wurde oder weil ich sie lokal geändert habe.

  • Paketsignierung (anscheinend wird daran gearbeitet ).

Da Arch leicht ist, ist der einzige wirkliche Grund, dass nur wenige Pakete standardmäßig installiert sind und Sie aufgefordert werden, das hinzuzufügen, was Sie gerade benötigen. Wenn Sie also standardmäßig keine optionalen Abhängigkeiten installieren, werden Benutzer wahrscheinlich zur Installation angeregt, um ein Aufblähen zu vermeiden.

Gentledevil
quelle
Ich kann das nicht analysieren, aber ich kann darauf verzichten und übrigens wissen, was ich besser mache . Es gibt auch einen Tippfehler im letzten Satz.
Tshepang
In welcher Sprache ist der Pacman-Paketmanager geschrieben? Verfügt es über Funktionen zur Paketverwaltung auf niedriger und hoher Ebene, die dpkg / apt ähneln, und wenn ja, wie heißen sie?
Faheem Mitha
@ Tshepang: Entschuldigung, nicht englischer Muttersprachler hier. Ich meinte "es ist keine große Sache für mich, diese Funktionalität (debconf) nicht zu haben, und indem ich gezwungen werde, Dinge manuell zu tun, zwinge ich mich zu wissen, was genau getan wird".
Gentledevil
@Faheem Mitha: Pacman ist in C geschrieben und ein Frontend für libalpm, das sowohl die Paketverwaltung auf "hoher" als auch auf "niedriger Ebene" verwaltet.
Gentledevil
@zanko: Ich bin auch kein Muttersprachler. Ich wollte nur, dass Sie den Satz klarer machen, und zwar nicht in einem Kommentar, sondern auf dem Beitrag selbst. Übrigens ist der Tippfehler, den ich erwähnt habe, optional . Ich könnte den Beitrag selbst bearbeiten, aber ich dachte, Sie könnten ihn genauso gut zusammen mit dem Klärungsteil reparieren.
Tshepang
6

Ich habe meine Linux-Reise mit Ubuntu lucid begonnen und benutze derzeit Arch. Ich habe eine Handvoll Arch-Pakete geschrieben, und ich werde sagen, es ist viel einfacher als Debian-Pakete zu schreiben. Aber ich möchte @gentledevil darauf hinweisen, dass Arch ein Hooks-System für Pakete hat, das als install file.

Grundsätzlich ist es benannt ${pkgname}.installund enthält einige Funktionen für vor / nach der Installation / Entfernung / Aktualisierung; Platzieren Sie einfach Ihre Font-Cache-Updates darin und so weiter und es funktioniert ungefähr genauso wie die Debian-Hooks.

Außerdem stelle ich fest, dass Sie erwähnt haben, dass eine Anwendung mit Debian-Paketverwaltungstools "gepinnt" wird. Arch's Pacman hat diese Funktion ebenfalls integriert und /etc/pacman.confakzeptiert eine Reihe von Einstellungen, einschließlich IgnorePkg =, die Upgrades von Paketen verhindern, die nach dem Gleichwert aufgelistet sind (durch Leerzeichen getrennt).

hanetzer
quelle
1
Auch wenn es sich nicht um ein Repo-Paket handelt, können Sie den powerpillWrapper für Pacman verwenden, um mehrere Pakete parallel herunterzuladen. Statt pacman -S libfoo libbar libbazjedes Paket nacheinander herunterzuladen, werden stattdessen alle drei Pakete gleichzeitig heruntergeladen, wodurch die Upgrade-Geschwindigkeit für bessere Verbindungen erheblich erhöht wird.
Hanetzer
-1

Bevor ich zu weit gehe, studieren Sie die Pictorial Linux Timeline

Um die Unterschiede bei den Paketmanagern zu verstehen, müssen Sie die Philosophien der oben abgebildeten Betriebssysteme verstehen


Drei Haupteltern

  1. Redhat, jetzt Fedora - Package Manager - RPM, kurz für Redhat Package Manager, Befehlszeile rpm
  2. Slackware - Package Manager - tgz, gewöhnliche komprimierte Dateien. Obwohl es sich nur um komprimierte Dateien handelt, wurden diese von Slackware im Upstream erstellt und in einem Repository abgelegt, das manchmal als Port bezeichnet wird
  3. Debian - DEB, kurz für Debian, ist das Kommandozeilen-Tool Aptitude or Apt

Diese Eltern sind Mütter und Väter der meisten Verteilungen, die wir heute kennen. Die Idee / das Konzept eines Paketverwaltungssystems wurde in irgendeiner Form oder Weise abgeleitet oder geteilt. Unabhängig davon sind alle diese übergeordneten Elemente Binärverteiler. Dies bedeutet, dass ein Programm von einem Drittanbieter gepackt und festgelegt, dann in einem Repository gespeichert und von der Benutzerbasis verwendet oder installiert wird.

3 minderjährige Eltern

  1. Linux From Scratch - Quellbasiert, kein Paketmanager.
  2. Gentoo - Abgeleitet von Linux von Grund auf neu . Diese Distribution besteht im Wesentlichen aus Linux von Scratch und einem Paketmanager namens Portage / emer
  3. SourceMage - Paketmanager-Zauberei

Diese Eltern sind minderjährig, weil ihre Nutzerbasis Geschwindigkeit und einfache Installation mit Leistung und einfacher Konfiguration verbindet. Jedes Paket wird unter Verwendung von Variablen und Konfigurationsdateien von Grund auf heruntergeladen und kompiliert.

Die Brücke

Arch wurde als Brücke zwischen einer binären Verteilung wie einem der drei Haupteltern und einer quellenbasierten Verteilung wie einem der drei Haupteltern erstellt. Als solches erhält es den Status eines übergeordneten Elements in der Zeitleiste, da kein anderes übergeordnetes Element diese Funktionalität bereitgestellt hat. Pacman bietet die Flexibilität, einem Benutzer die Installation eines Binärpakets aus einem offiziellen Repository oder eines benutzerdefinierten Pakets mithilfe des Arch Build Systems zu ermöglichen. Dieses Konzept bietet ein Gleichgewicht zwischen der Leistung, die die minderjährigen Eltern geben, und der einfachen Installation, die die großen Eltern geben.


Meiner Meinung nach ist es nicht der Paketmanager, der die Leistungsfähigkeit eines Systems zeigt, da alle Paketmanager dieselbe Aufgabe ausführen, nämlich ein gesundes System zu verwalten und zu warten. Daher sollte das von Ihnen verwendete System durch Faktoren wie Folgendes bestimmt werden:

  • Benutzerebene: Jemand, der neu in Linux ist, sollte mit einem Hauptelternteil beginnen, während jemand, der technisch versiert ist, ein Gleichgewicht findet.
  • Was Sie mit Ihrem System tun möchten: Das Ausführen eines LAMP-Servers mit angeschlossenen Benutzern unterscheidet sich grundlegend vom Ausführen eines Desktop-PCs zum Surfen im Internet und zum Lesen von E-Mails.
  • Komfortstufe: Wenn Sie technisch versiert sind, aber kein Wochenende damit verbringen möchten, ein System zu kompilieren, wählen Sie einen Hauptelternteil, unabhängig davon, ob jeder, den Sie kennen, etwas anderes wählt.
eyoung100
quelle
Dies konzentriert sich mehr auf die Geneaologie der Distributionen als auf einen Vergleich der Paketverwaltungstools von Pacman und Debian ...
Jasonwryan,
@jasonwryan Das ist der Punkt, da alle Paketmanager die gleiche Aufgabe ausführen, dh emerge packagenamedie gleiche wie sudo apt-get install packagename.
eyoung100
Auf dieser Ebene ja; aber das verfehlt völlig den Punkt der Frage, dh was Pacman von {apt, aptitude} unterscheidet.
Jasonwryan
@ jasonwryan Ich habe das im Abschnitt The Bridge beantwortet. Davon abgesehen gibt es keinen Unterschied. Die einzigen Unterschiede sind semantisch, dh ein Befehl gegen einen anderen. Wenn das OP nach semantischen Unterschieden sucht, gibt es dafür ein Handbuch.
eyoung100
-3

Dies ist keineswegs eine vollständige oder erschöpfende Antwort - die Plakate vor mir gaben bereits einige sehr gute Punkte, ich möchte nur meine 2 Cent hinzufügen. Eine andere Sache - ich habe mich nie wirklich an apt / dpkg gewöhnt. Es schien mir immer zu komplex zu sein, ich fühle mich mit yum / rpm wirklich am wohlsten.

pacman ist sehr einfach zu bedienen, was ein Vorteil und ein Nachteil ist - Sie können lernen, es an einem einzigen Nachmittag zu verwenden (abgesehen von der Paketerstellung) - es verwendet meist intuitive und vollständige Funktionen zur Paketverwaltung, aber - und das ist ein großes, aber - es ist extrem unflexibel.

Wenn die Designer vorher nicht an ein Feature gedacht haben, sind Sie fertig.

Einige Beispiele: In Pacman gibt es keine native Versionierung. Wenn Sie eine Paketversion herunterstufen möchten, müssen Sie diese bestimmte Paketversion herunterladen und die Option -U (Upgrade) verwenden, um sie aus einer Datei zu installieren. Es ist sehr darauf ausgerichtet, immer modernste Pakete in Ihrem System zu verwenden.

Es gibt keine echte interne Cache-Bereinigung / vollständige Neuerstellung. Wenn (aufgrund eines Netzwerkproblems) ein Paket-Download beschädigt wurde, z. B. während -Syu, ist die Fehlermeldung zwar korrekt, aber nicht von großem Nutzen - sie kann das beschädigte Paket auch bei aktivierter "vollständiger" Ausführlichkeit und Debug nicht lokalisieren und keine Menge von -Syyc wird den Cache wirklich bereinigen und die Pakete erneut herunterladen. Die gute Nachricht ist, dass -Sc Sie darüber informiert, wo sich die heruntergeladenen Pakete befinden, sodass Sie einfach das fehlerhafte (wenn Sie herausfinden können, welches es ist) oder alle entfernen und -Syu neu starten können.

Die Pacman-Integration mit dkms ist ebenfalls etwas problematisch - während der Installation eines neuen Kernels hatte ich immer wieder Fehler von dkms. Die Verwendung von dkms build && dkms install gegen den neuen Kernel funktionierte reibungslos, aber pacman würde keinerlei Informationen darüber liefern, warum dkms während des Kernel-Upgrades fehlgeschlagen ist (ich vermute, dass es nie den richtigen Pfad des neuen Kernels übergeben hat, und lassen Sie dkms einfach den Standard verwenden (aktuell laufender) Kernel aber mit falscher Version).

Eine weitere Anekdote über die Inflexibilität - wie gesagt, ich bin an U / min gewöhnt. Wenn ich eine Datei auf meinem System habe und wissen möchte, welches Paket sie besitzt, kann ich yum deploy / path / to / file ausführen und ALLE Pakete abrufen, die sie dort ablegen können - auch wenn keines davon installiert ist. Wenn die Datei manuell abgelegt wurde und ich jetzt ein Paket installieren möchte, wird das neue umbenannt (Erweiterung .rpmnew hinzufügen), und ich kann auswählen, was verwendet werden soll.

pacman macht einfach einen Fehler, dass eine Datei bereits vorhanden ist, aber mit einer völlig irrelevanten Fehlermeldung - es klagt über Konflikte zwischen dem "wahren" Eigentümer der Datei und dem aktuell installierten "Dateisystem" -Paket, als ob es auch ein Eigentümer derselben Datei wäre. Außerdem ist es hauptsächlich auf lokal installierte Informationen ausgerichtet - der Versuch, Informationen (wie Dateilisten und Besitz) von noch nicht installierten Paketen zu erhalten, ist weniger intuitiv.

Einfach ausgedrückt - es ist nicht so ausgereift wie lecker, und wahrscheinlich ist dpkg, was auch zu seiner Benutzerfreundlichkeit beiträgt, eine relative Inflexibilität.

Dani_l
quelle
1
Abgesehen von einer umfassenden Nichtbeantwortung gibt es eine Reihe von Punkten, die Sie ansprechen und die wirklich auf eine Unbekanntheit mit Pacman zurückzuführen sind. Zum Beispiel pacman -Qo $fileerfahren Sie, welches Paket $ file besitzt. Außerdem ist Ihre ganze Antwort ein Strohmann, da das OP ausdrücklich nach Unterschieden zwischen Arch und Debian gefragt yumhat - hat nichts damit zu tun ...
Jasonwryan
Deshalb habe ich diese Tatsache zu Beginn meiner Antwort ausdrücklich offengelegt. Was die -Qo $ -Datei betrifft - haben Sie das jemals für ein noch nicht installiertes Paket versucht?
Dani_l
Es macht keinen Sinn, es für ein nicht installiertes Paket zu versuchen. Dafür gibt es andere Werkzeuge. Und die Offenlegung mindert nicht die Tatsache, dass Sie die Frage nicht beantwortet haben: Ein "Vergleich" zwischen yum und pacman ist nicht dasselbe wie die Unterschiede zwischen den Paketmanagern von Debian und Arch.
Jasonwryan
@ Jasonwryan Natürlich gibt es einen Punkt. Nur weil Sie nicht sehen müssen, welches Paket eine Datei besitzen könnte, auch wenn sie noch nicht installiert ist, heißt das nicht, dass ein solcher Bedarf nicht besteht. Das war der Punkt. Was andere Tools betrifft - müssen sie wissen? Pacman ist der Paketmanager. In Bezug auf Ihren Hauptpunkt - Ich habe die Frage möglicherweise völlig falsch verstanden, aber ich nahm an, dass es sich um eine leichte PM im Vergleich zu einer komplexeren PM handelt. Ich gehe davon aus, dass apt / dpkg mindestens so komplex ist wie yum / rpm.
Dani_l
Mein Punkt ist, dass Sie eine Frage zum Vergleich von Äpfeln mit Orangen beantworten, indem Sie Ihr begrenztes Verständnis von Äpfeln mit Birnen vergleichen. Und ja, Sie haben die Frage völlig falsch verstanden ...
Jasonwryan