Titel: Ist die Benutzung von pacman kryptisch?
Beitrag von: Sebastian am 04. Oktober 2022, 08:34:24
Heute habe ich ein Artikel (https://gnulinux.ch/keep-rolling-ein-subjektiver-vergleich-verschiedener-rollender-distros) auf gnulinux.ch gelesen, wo der Autor sinngemäß meinte, dass der Umgang mit dem Paketmanager pacman Kryptisch sei, und andere Paketmanager wie apt usw. durch die einfachere Beschreibung der Befehle einfacher mit umzugehen ist.
Ein weiterer Aspekt, den ich an Arch nicht wirklich leiden kann, ist der Paketmanager Pacman -- und schon höre ich die ersten Arch Nutzer/-innen schreien. Ja, Pacman ist verdammt schnell, ja, das verwendete Paketformat mag wesentlich verständlicher sein als deb und RPM zusammen, dennoch: Pacman ist und bleibt verdammt kryptisch, wenn man dpkg- oder RPM-basierte Paketverwaltungen kennt.
Was wäre bitte falsch an 'pacman update' statt 'pacman -Syu'? Warum muss ich erst das halbe Alphabet in die Kommandozeile hämmern, um an die Funktionalität eines 'apt autoremove && apt autoclean' heranzukommen?
Was spart am Ende mehr Zeit: Eine kryptische Paketverwaltung, die ich mir vor der ersten Nutzung ersteinmal mehrere Stunden aneignen muss, nur weil die Pacman-Entwickler/-innen anscheinend auf Kommando-Neologismen stehen oder eine leicht zu erlernende Paketverwaltung, die pro Kommando vielleicht fünf Sekunden länger braucht?
|
|
Wie empfindet ihr den Umgang mit pacman?
Ich empfinde die Befehlssyntax von pacman eigentlich sehr schnell, angenehm und konsequent umgesetzt. Wenn man erst einmal verstanden hat, dass jeder Großbuchstabe eine Hauptfunktion und jeder Kleinbuchstabe eine Option zu der jeweiligen Hauptfunktion darstellst, ist man eigentlich schnell in der Lage, mit der jeweiligen --help Option die gesuchten Kommandos nachzuschlagen, wenn diese noch nicht in Fleisch und Blut übergegangen sind.
Ein typischer Gedankenweg kann solch einer sein:
Ich möchte gerne mein System mit den Arch Repositorys synchronisieren, damit mein System auf demselben Stand ist wie in den Repos, wie mache ich das? Die passende Hauptfunktion ist passender weiße -S (--sync) also schaue ich doch mal schnell in deren Hilfe für diese Funktion nach:
Code:
pacman -S --help
Verwendung: pacman {-S --sync} [Optionen] [Paket(e)]
Optionen:
-b, --dbpath <Pfad> legt einen anderen Ort für die Datenbank fest
-c, --clean entfernt alte Pakete aus dem Paketpuffer (-cc für alle).
-d, --nodeps Überspringt die Versionsüberprüfungen für Abhängigkeiten
(-dd überspringt alle Überprüfungen)
-g, --groups zeigt alle Elemente einer Paket-Gruppe an
(-gg zeigt alle Gruppen samt Elementen an)
-i, --info zeigt Paketinformationen an
(-ii liefert erweiterte Informationen)
-l, --list <repo> zeigt eine Liste aller Pakete eines Repositoriums an.
-p, --print zeigt die Ziele an, statt die Operation auszuführen
-q, --quiet zeigt weniger Information bei Abfragen und Suche an.
-r, --root <Pfad> legt ein alternatives Wurzelverzeichnis zur Installation fest
-s, --search <regex> durchsucht ferne Repositorien nach passenden Zeichenketten.
-u, --sysupgrade aktualisiert installierte Pakete (-uu ermöglicht Herunterstufungen).
-v, --verbose aktiviert ausführliche Ausgaben
-w, --downloadonly lädt Pakete herunter, ohne etwas zu installieren oder aktualisieren.
-y, --refresh lädt aktuelle Paketdatenbanken vom Server herunter
(-yy aktualisiert auch aktuelle Datenbanken).
--arch <Arch.> legt eine alternative Architektur fest
--asdeps installiert Pakete als nicht-ausdrücklich installiert.
--asexplicit installiert Pakete als ausdrücklich installiert.
--assume-installed <Paket=Version>
fügt ein virtuelles Paket hinzu, um Abhängigkeiten zu erfüllen
--cachedir <Verzeichnis>
legt einen anderen Ort für den Paketzwischenspeicher fest
--color <wann> stellt die Ausgabe farbig dar.
--config <Pfad> legt eine alternative Konfigurationsdatei fest
--confirm fraht immer nach einer Bestätigung
--dbonly verändert nur Datenbank-Einträge, keine Paketdateien
--debug zeigt Debug-Meldungen an
--disable-download-timeout
verwendet großzügige Zeitüberschreitungen für Downloads
--gpgdir <Pfad> legt ein alternatives Konfigurationsverzeichnis für GnuPG fest
--hookdir <Verzeichnis>
legt ein anderes Hook-Verzeichnis fest
--ignore <Pak.> ignoriert ein neues Paket (kann mehrfach genutzt werden)
--ignoregroup <Gruppe>
ignoriert Aktualisierung einer Gruppe (kann mehrfach genutzt werden).
--logfile <Pfad> legt eine alternative Log-Datei fest
--needed installiert aktuelle Pakete nicht erneut.
--noconfirm fragt niemals nach einer Bestätigung
--noprogressbar zeigt keinen Fortschritt an, wenn Dateien heruntergeladen werden
--noscriptlet führt kein Installationsskript aus, falls vorhanden
--overwrite <glob>
kollidierende Dateien überschreiben
(kann mehrmals angegeben werden)
--print-format <Zeichenkette>
legt fest, wie die Ziele ausgegeben werden sollen.
--sysroot arbeitet auf einem eingehängten Gastsystem (nur Root)
|
|
In dieser Ausgabe findet man schnell die zwei benötigend Optionen -yu, die man brauch, um sein System zu aktualisieren.
Code:
Klar könnte man jetzt sagen, wer kommt auf das Stichwort Synchronisieren, wenn man sein System auf dem neusten Stand bringen möchte? Schließlich denkt man doch eher an das Stichwort Update. Das ist in der Tat etwas, was man nur aus dem Handbuch von pacman erfährt, durch dessen Studium erfährt man erst so richtig, warum gewisse Begrifflichkeiten wie synchronisieren gewählt wurden. Beim Studium des Handbuchs wird man auch schnell merken, dass diese Bergriffe aufgrund dessen, wie pacman arbeitet durchaus Sinn machen.
Das gleiche gild aber auch für andere Paketmanager wie apt. Manche Begrifflichkeiten erfährt man auch hierbei nur aus dem Handbuch:
Oder warum wird für die gleiche Sache zwei unterschiedliche Begrifflichkeiten in apt genannt?
full-upgrade (apt-get(8))
full-upgrade performs the function of upgrade but will remove currently installed
packages if this is needed to upgrade the system as a whole.
|
|
dist-upgrade
dist-upgrade in addition to performing the function of upgrade, also intelligently
handles changing dependencies with new versions of packages; apt-get has a "smart"
conflict resolution system, and it will attempt to upgrade the most important packages
at the expense of less important ones if necessary. The dist-upgrade command may
therefore remove some packages. The /etc/apt/sources.list file contains a list of
locations from which to retrieve desired package files. See also apt_preferences(5)
for a mechanism for overriding the general settings for individual packages.
|
|
Da finde ich pacman schon konsequenter. Wenn man einmal gelernt hat das -i für Information steht, dann funktioniert -i auch bei allen anderen Hauptfunktionen von pacman wo das sinn macht wie z.B. -Si, -Qi oder auch wenn man -i zweimal angibt das man mehr Informationen bekommen möchte ist dann in allen Hauptfunktionen konsequent umgesetzt. Genauso das man dadurch die Erfahrung macht das bestimmte Optionen, zweimal angegeben werden können, um seinen Wunsch mehr Dringlichkeit zu verleiten: -ii = Mehr Informationen, yy = erzwinge ein Datenbank update usw. man erkennt überall ein konsequentes muster.
Zudem stand in dem Artikel auch noch folgendes:
Erschwerend kommt noch hinzu, dass Arch nicht wirklich für GNU/Linux-Anfänger geeignet ist: So lange die Einsteigerdistros in der Debian-Familie angesiedelt sind, vielleicht in Einzelfällen auch in der RPM-Welt vertreten sein mögen, werden sich Einsteiger zunächst mit apt, zypper oder dnf vertraut machen - Pacman mag noch so technisch weiterentwickelt sein, schlussendlich könnte man an der eigenen Kryptifizierung scheitern.
Ich möchte Arch hier keinesfalls schlecht reden: Eine Arch-Installation nach klassischer Vorgehensweise halte ich für sehr lehrreich, da man früher oder später auf Paketsuche gehen muss, um einen vollständigen Desktop zu erhalten -- dahingehend kann man eigentlich nur dazulernen.
|
|
Meint ihr auch das Arch nicht einsteigerfreundlich ist, weil Einsteiger Distros eher bei Debian angesiedelt sind?
Ich würde sagen, es kommt ganz auf den Einsteiger drauf an, wie er einsteigen möchte. Mit der Bereitschaft, alles von der Picke auf zu lernen (hohe Lernbereitschaft vorausgesetzt). Oder doch lieber nur nutzen/konsumieren und es soll einfach nur laufen und mit technischen Details möchte man sich nicht auseinandersetzten. Für die zweite Personengruppe empfihlt es sich doch wohl eher eine auf Debian basierte Distro (wenn man mit alter Software leben kann) oder eine Arch distro, wenn man jemanden an der Hand hat, der für einen das Wissen hinterherträgt, auf dem man sich dann verlassen muss.
Noch einen Satz zum Wissen hinterhertragen. Es ist völlig in Ordnung, wenn man sich nicht mit jeder Materie völlig auseinandersetzten möchte. Ich bringe mein Auto ja auch schließlich in eine Werkstatt, weil es mich schlicht und einfach nicht interessiert, wie der Motor oder andere Dinge am Auto funktionieren. Ich will es einfach nur nutzen können. Man muss sich diesbezüglich dann nur bewusst sein, dass man somit auf andere angewiesen ist und diese es eventuell nicht kostenlos machen. So entstehen halt Geschäftskontakte ;) |
Titel: Re:Ist die Benutzung von pacman kryptisch?
Beitrag von: Andreas am 04. Oktober 2022, 09:39:36
Hallo Seabstian,
ich bin schon erschrocken über den Autor der so eine Äußerung macht. Allerdings zeigt es deutlich wohin auch in den besser gebildeten IT-Kreisen der Zug geht: weniger denken, mehr auswendig lernen (um copy & paste machen zu können).
Ich habe jahrzehte(!!)lang Debian-basierte Systeme gepflegt. Es begann mit Ubuntu, dann folgte ein "reines Debian", dann "LMDE" und zuletzt "Siduction". Ich hatte mich an die Aufspaltung der Systempflege in die beiden Tools "apt" und "dpkg" gewöhnt. Es erforderte gerade bei Problemen schon sehr viel Erfahrung was man mit welchem Tool in welcher Reihenfolge tun musste um Probleme zu lösen.
Beim ersten Arbeiten mit Arch war ich total baff. EIN einziges Tool für die Paketpflege - nämlich "pacman"? Und so gut organisierte und strukturierte Kommandos und intuitiv zudem? Mit "S" (sync) geht es immer um Installationen, mit "Q" (query) werden die auf dem System installierten Pakete anvisiert, mit "R" (remove) wird entfernt, mit "U" (upload) wird ein lokales Paket angesprochen. Ich war wochenlang am zweifeln wann dann noch das große AHA-Erlebnis ("nein - ganz so einfach geht es nun doch nicht") kommt - aber es blieb aus. Bis heute. Ich kann tatsächlich mit einem einzigen Befehl (pacman) kein System auf dem Laufenden halten, mir installierte Pakete anschauen, sie entfernen oder neue installieren. Kein weiterer Eingriff mit einem zweiten Tool notwendig - "dpkg" ade!
Gut. Wenn man die volle Leistungsfähigkeit haben will braucht es die Intelligenzpower von hunderttausenden von Menschen mit ihren "User Repositories" - den AURs. Und die kann pacman nicht bedienen - und will es auch gar nicht. Im Original-Arch wird ausdrücklich gesagt "man übernimmt keinerlei Garantie dafür dass die Pakete von Usern funktionieren oder Schaden herbeiführen könnten" - eine durchaus nachvollziehbare und richtige Entscheidung. Ganz im Gegensatz zu dem was in der "normalen" Welt gerade in Sachen "Zusammenarbeit", gegenseitiger Respekt und Achtung vor sich geht scheint das in den AURs aber zu funktionieren. Die AURs enthalten eine gewaltige Menge von ausgezeichneten Programmen, sie sind nicht schlechter gepflegt als dei in den Standard-Repositories und seit ich Arch betreibe war dort auch noch kein einziges Sicherheitsproblem (Trojaner etc.) . Der Clou: Der Anwender braucht sich nur sehr, sehr wenig damit zu beschäftigen, wie aus dem Quellcode ein Programmpaket entsteht! Er braucht nur das Werkzeug "yay", das bildlich gesehen ein pacman mit Erweiterungen ist. Bedeutet: das "ganze Alphabet" was der Autor meinte gilt auch hier!
Nein - pacman / yay ist nicht "kryptisch". Das würde bedeuten dass es einer Logik folgt die nicht nachvollziehbar ist. Das Gegenteil ist der Fall. Die Logik ist ausgezeichnet nachvollziehbar, und die Parameter im Befehl lehnen sich so gut wie alle an englische Wörter an. Besser geht es nicht.
Für jemanden der nicht lernen WILL ist alles neue kryptisch. Das gilt in jedem Bereich.
Lieber Autor, kleiner Tipp von mir: Open up your mind and start to learn!
Und zu der Bemerkung "Arch ist nicht für Einsteiger geeignet" gibt es in der aktuellen Linux-User einen tollen Beitrag zu EndeavourOS (https://www.linux-community.de/ausgaben/linuxuser/2022/07/endeavouros-im-test/). Ich bin der letzte der irgendjemand zu "Konsum" auffordern will. Wer jedoch in Sachen "Linux" breiter informiert werden möchte kann und darf sich nicht allein auf das Internet verlassen. Sicher steht dort fast alles was man braucht: aber man muss es auch gefunden haben. Das erledigen die Mitarbeiter / Journalisten des Linux-User und des Linux-Magazin (ersteres für diejenigen die Linux mehr anwenden wollen als ins System einsteigen, letzteres für die die überall wo es was zu lernen gibt "die Motorhaube aufklappen").
EDIT:
Nach meiner Ansicht hat EndeavourOS (https://endeavouros.com/) eine sehr gute Chance die "Führung" unter den Linux-Distributionen zu übernehmen. Es hat das modernste und aktuellste Basis-System (Arch), bleibt zu diesem auch 100% kompatibel (im Gegensatz zu Manjaro), fügt das dazu was die Anfänger brauchen (einen schicken einfachen Installer) und hat ein "Marketing-Konzept" wie man die Usergemeinde vergrößert - ohne Kommerz-Hintergedanken. Das ist schon ein echter Meilenstein.
LG
Andreas |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|