Unterschiede in der Paketverwaltung zwischen Debian und Arch

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

• Dies ist nur ein Eindruck, aber Pacman wirkt moderner und einfacher in seinem Design / seiner Architektur. Zumindest gibt es weit weniger Werkzeuge, mit denen man umgehen muss. Obwohl ich keinen passenden Quellcode kenne, habe ich mir gerade 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 durch die Sorge um einige Dinge (siehe unten)). Die letzte Version (Pacman 3.5, einige Tage alt) hat versucht, die Leistung zu verbessern, indem die Anzahl der reduziert wurde beteiligte Datenbankdateien.

• Während arch auf die Verwendung von Binärpaketen ausgerichtet ist, hat es auch Vorteile beim Erstellen von Paketen aus dem Quellcode mit einem Build-System, das den Ports von BSD ähnelt ( ABS).

• Es ist sehr einfach und schnell, Pakete zu erstellen, nur ein paar Zeilen in einer PKGBUILD-Datei und fertig, ohne sich mit Kontrolle / Regeln / Urheberrecht befassen zu müssen / changelog / wie auch immer mit Debian-Paketen. Und mit wenigen Klicks in einer Web-Benutzeroberfläche wird Ihr Paket für alle auf AUR (Arch User Repository) freigegeben.

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

• Trigger / h ooks (was apt dazu bringt, den Icon-Cache, das Mandb oder was auch immer zu aktualisieren, indem man sich nur ansieht, wo das Paket die Dateien installiert, ohne dass der Packager irgendetwas tun muss) (anscheinend gibt es plant , dies umzusetzen).

• debconf (keine große Sache, und wenn ich gezwungen bin, Dinge manuell zu tun, muss ich wissen, was genau getan wird) und ordnungsgemäße Behandlung neuer Konfigurationsdateien (Ich möchte zumindest, dass pacman weiß, wann sich eine Konfigurationsdatei in einer neuen Paketversion von der installierten unterscheidet, weil sie in der neuen Version geändert wurde oder weil ich sie lokal geändert habe).

• Paketsignatur (anscheinend wird bearbeitet ).

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 Aufblähen zu vermeiden .

Kommentare

• Ich kann ‚ dies nicht analysieren: aber ich kann darauf verzichten und weiß übrigens, was ich besser mache . Es gibt auch einen Tippfehler im letzten Satz.
• 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?
• @Tshepang: Entschuldigung, nicht englischer Muttersprachler hier. Ich meinte „, das 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 „.
• @Faheem Mitha: Pacman ist in C geschrieben und ein Frontend für libalpm, das beide “ high behandelt -level “ und “ Low-Level “ Paketverwaltung.

li> @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.

Ich habe meine Linux-Reise mit Ubuntu lucid begonnen und verwende 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 heißt es ${pkgname}.install und enthält einige Funktionen für die Installation vor / nach der Installation / Entfernung / Aktualisierung. Platzieren Sie einfach Ihre Font-Cache-Updates in diesem 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 „angeheftet“ wird; Arch s Pacman verfügt über diese integrierte Funktion Außerdem akzeptiert /etc/pacman.conf eine Reihe von Einstellungen, einschließlich IgnorePkg =, die Upgrades auf Pakete verhindern, die nach dem Gleichheitszeichen aufgelistet sind (durch Leerzeichen getrennt) )

Kommentare

• Auch wenn es sich nicht um ein Repo-Paket handelt, können Sie den Wrapper powerpill verwenden Damit Pacman mehrere Pakete parallel herunterladen kann, laden Sie statt pacman -S libfoo libbar libbaz jedes Paket nacheinander herunter r Es würde stattdessen alle drei gleichzeitig herunterladen und die Upgrade-Geschwindigkeit für bessere Verbindungen erheblich erhöhen.

Bevor ich Gehen Sie zu weit und studieren Sie die Pictorial Linux Timeline

Um die Unterschiede in den Paketmanagern zu verstehen, müssen Sie die Philosophien des Betriebssystems verstehen. “ es oben abgebildet

Drei Haupteltern

1. Redhat, jetzt Fedora – Package Manager – RPM, kurz für Redhat Package Manager, Befehlszeile rpm
2. Slackware – Package Manager – tgz, normale 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
3. Debian – DEB, kurz für Debian, bezeichnet wird. Das Befehlszeilentool lautet Aptitude or Apt

Diese Eltern sind Mütter und Väter der meisten Distributionen, die wir heute kennen. Die Idee / das Konzept eines Paketverwaltungssystems wurde in einigen abgeleitet oder geteilt Unabhängig davon sind alle diese Eltern Binärdistributoren. 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 Kleinere Eltern

1. Linux von Grund auf neu – Quellbasiert, kein Paketmanager.
2. Gentoo – Abgeleitet von Linux von Grund auf neu . Diese Distribution ist im Wesentlichen Linux von Grund auf neu und ein Paketmanager namens Portage / emer
3. SourceMage – Package Manager Sorcery

Diese Eltern sind aufgrund ihrer Benutzerbasis geringfügigTauscht Geschwindigkeit und einfache Installation mit Leistung und einfacher Konfiguration. Jedes Paket wird unter Verwendung von Variablen und Konfigurationsdateien von Grund auf neu heruntergeladen und kompiliert.

Der Bridge

Arch wurde als Brücke zwischen einer Binärdistribution wie einem der drei Haupteltern erstellt. und eine quellenbasierte Distribution wie eine der 3 minderjährigen Eltern. 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 der minderjährigen Eltern und der einfachen Installation, die die großen Eltern bieten.

Meiner Meinung nach ist es nicht der Paketmanager, der die Leistung von a zeigt System, da alle Paketmanager dieselbe Aufgabe ausführen, nämlich die Verwaltung und Wartung eines fehlerfreien Systems. Daher sollte das von Ihnen verwendete System durch Faktoren wie Folgendes bestimmt werden:

• Benutzerebene: Jemand Neu in Linux sollte mit einem Hauptelternteil beginnen, während jemand mit technischen Kenntnissen 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 für das Surfen im Internet und das Lesen von E-Mails.
• Komfortstufe: Die Benutzerebene hält nicht aus, 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.

Kommentare

• Dies ist mehr Fokus verwendet auf der Geneaologie der Distributionen, anstatt einen Vergleich der Paketverwaltungstools von pacman und Debian ‚ …
• @jasonwryan That ‚ ist der Punkt, da alle Paketmanager dieselbe Aufgabe ausführen, dh emerge packagename ist dasselbe wie sudo apt-get install packagename.
• Auf dieser Ebene ja; Aber das lässt den Punkt der Frage völlig außer Acht, dh was Pacman von {apt, aptitude} unterscheidet.
• @jasonwryan Ich habe das im Abschnitt The Bridge beantwortet. Davon abgesehen gibt es keinen Unterschied. Die einzigen Unterschiede sind semantisch, d. H. Ein Befehl gegen einen anderen.Wenn das OP nach semantischen Unterschieden sucht, gibt es dafür ein Handbuch.

Dies ist von nein bedeutet 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 immer zu komplex zu sein Ich fühle mich mit yum / rpm 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 (Paketbau beiseite) – Es verwendet hauptsächlich intuitive und vollständige Funktionen zur Paketverwaltung, aber – und das ist ein großes, aber – es ist äußerst unflexibel.

Wenn die Designer vorher nicht an eine Funktion 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 der Datei zu installieren ist sehr auf alwa ausgerichtet Sie verwenden modernste Pakete auf Ihrem System.

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 & & Die Installation von dkms gegen den neuen Kernel funktionierte reibungslos, aber pacman bot keinerlei Informationen darüber, warum dkms während des Kernel-Upgrade (Ich vermute, es hat nie den richtigen Pfad des neuen Kernels übergeben und nur dkms den Standard-Kernel (aktuell ausgeführt) verwenden lassen, aber mit falscher Version).

Eine weitere Anekdote über die Inflexibilität des Kernels – as angegeben, ich bin es gewohnt, U / min / yum. 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 nun ein Paket installieren möchte, wird das neue umbenannt (Erweiterung .rpmnew hinzufügen), und ich kann auswählen, was verwendet werden soll.

pacman gibt einfach einen Fehler aus, dass eine Datei bereits vorhanden ist existiert, 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 ist. 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 yum, und wahrscheinlich dpkg, was auch zu seiner Benutzerfreundlichkeit führt, ist die relative Inflexibilität.

Kommentare

• Kurz vor einer umfassenden Nichtantwort, Es gibt eine Reihe von Punkten, die Sie ansprechen und die wirklich auf eine Unbekanntheit mit Pacman zurückzuführen sind. Zum Beispiel sagt Ihnen pacman -Qo $file, welches Paket $ file besitzt. Außerdem ist Ihre gesamte Antwort ein Strohmann, da das OP ausdrücklich nach Unterschieden zwischen Arch und Debian gefragt hat – yum hat nichts damit zu tun …
• 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?
• Es macht keinen Sinn, es für ein nicht installiertes Paket zu versuchen. Dafür gibt es andere Werkzeuge. Und die Offenlegung ‚ mildert nicht die Tatsache, dass Sie ‚ die Frage nicht beantwortet haben: a “ Vergleich “ zwischen yum und pacman ist nicht gleich den Unterschieden zwischen Debian ‚ s und Arch ‚ Paketmanager.
• @jasonwryan Natürlich gibt es einen Punkt. Nur weil Sie nicht ‚ sehen, müssen Sie nicht herausfinden, welches Paket möglicherweise eine Datei besitzt, auch wenn ‚ noch nicht installiert ist ‚ bedeutet nicht, dass ein solcher Bedarf ‚ nicht besteht. Das war der Punkt. Wie bei anderen Tools – 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, was die Funktionen betrifft.
• 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 …