Unterschiede in der Paketverwaltung zwischen Debian und Arch

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

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.

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

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.

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.