DK36: Paketmanager unter Linux
Auf eurem Computer befindet sich neben dem Kernel meist Anwendungssoftware, wie ein Browser, ein Mailprogramm und anderes. Alle diese Software muss irgendwann aktualisiert werden. Unter Windows kümmert sich Microsoft um die eigenen Programme. Anwender müssen sich in der Regel um die Programme kümmern, die sie selbst installiert haben.
Linux bringt eine Software mit, die Informationen zu einer großen Auswahl an Software hat. Damit lassen sich verschiedene Programme installieren und wieder löschen. Auch Aktualisierungen werden darüber eingespielt. Dieser Paketmanager übernimmt eine Reihe an Aufgaben und je nach Distribution sieht das ein wenig anders aus.
Wir betrachten in der Sendung verschiedene Lösungen und fangen bei der Verwaltung mittels Archivdateien (tar.gz) an. Danach besprechen wir die Interna bei Debian und gehen auf den RPM Package Manager ein. Gegen Ende müssen wir ein wenig eher aufhören. Daher bleibt für die Ebuilds von Gentoo zu wenig Zeit.
Download und Anhören
Musik
Wurde in der Sendung keine gespielt.
Comments
Display comments as Linear | Threaded
Anonymous on :
für die -nennen wir sie mal Low-Level Paketmanager" wart Ihr ja recht ausführlich. dpkg kann man durchaus mit rpm in ihren Aufgaben vergleichen.
Hier die erste Ergänzung, die auch einem Sysadmin durchaus von Nutzen sein könnte:
http://inai.de/linux/adm_pack.php
Zu den “High-Level”-Paketmanagern will ich dann noch kurz die entsprechenden Werkzeuge der “RPM-Welt” nennen.
Was für Debian&Co. apt-get (bzw. aptitude, wobei das mMn schon ein wenig in Richtung Frontend/GUI geht), ist für
- Fedora: yum
- Mageia/Mandriva: urmpi
- openSUSE/SLES/SLED: zypper (rug)
So ein Tool wie YaST (genauer die Module “sw_single” oder “online_update”) würde ich dann eher mit synaptic vergleichen, ich bin mir sicher, für Fedora/Mageia gibt es da Vergleichbares, aber diese Tolls kenne ich nicht (womit klar sein dürfte, welche RPM-basierte Distribution ich verwende, aber das nur am Rande).Ansonsten, mal wieder eine interessante Sendung und ich freue mich schon auf weitere Datenkanäle zu solchen Themen.
Jens Kubieziel on :
Anonymous on :
Allerdings hätte ich da eine Anregung, vielleicht auch interessant für Jörg, der ja kurz angesprochen hat, daß Pakete bauen dann zum Thema wird, wenn man Software reproduzierbar/standardisierbar/etc. auf diversen Systemen deployen will.
Das Ganze war mal “RPM-Welt”, aber mittlerweile ist das auch auch für Leute aus der Debian-Welt vielleicht einen Blick wert
Der “open build service”, der zu Beginn mal openSUSE Build Service hiess, aber mittlerweile auch Infrastruktur für diverse andere Distributionen (SUSE, Fedora, Mageia, Debian, Ubuntu und Archlinux) zur Verfügung stellt.
https://build.opensuse.org/
bzw.
http://openbuildservice.org/
Das kann man z.B. auch für lokale Testbuilds mit standardisierten Umgebungen (Distributiuon X in Version Y) nutzen ohne diese Pakete dann auch veröffentlichen zu müssen, wobei das natürlich schon die Idee hinter diesem Projekt ist.
Ich persönlich nutze diese Infrastruktur zum Bau von RPM-Paketen meist für den Eigengebrauch, einige der Pakete veröffentliche ich aber auch.
So können dann andere User mein Repository einbinden und meine Pakete nutzen, wenn sie mir denn trauen
Kann vielleicht als Testumgebung zur Paketierung sehr nützlich sein, zumindest für RPMs hat man dann auch automatisierte Tests, ob das eigene Paket auch den Packaging Guidelines der Zieldistro entspricht.
Jens Kubieziel on :
Ich glaube, ich hatte die reproducible builds angesprochen. Lunar hat kürzlich dazu gebloggt. Das finde ich sehr spannend.
Ist die Infrastruktur für das Bauen der RPMs vergleichbar zu dem, was Launchpad für Ubuntu macht?
Anonymous on :
Ein großer Vorteil des OBS ist mMn die Verfügbarkeit der Infrastruktur für verschiedene Distributionen, man muss sich nicht die passenden Pakete für das (lokale) Bauen zusammensuchen.
Wer versiert genug ist, kann praktisch für die ganzen genannten Distros das selbe Paket in einem Projekt bauen und veröffentlichen lassen.
Für einige Distros (openSUSE weiß ich es sicher) gibt es dann auch zwei “Standard-Umgebungen”, zunächst die Distro auf dem Stand des Releases und zusätzlich die distro mit allen verfügbaren Updates, gerade bei Paketen mit Kernelmodulen sehr wichtig, damit das Modul zur Kernelversion passt.
Man bekommt als normaler Nutzer automatisch sein eigenes “home”-Projekt und sofern man sein Projekt so konfiguriert hat, werden die fertigen Pakete dann auch für jeden Nutzer verfügbar veröffentlicht.
Wie die Vorgehensweise auf der lokalen Maschine aussieht, kann ich für Launchpad nicht sagen, aber ich kann es mal für OBS kurz beschreiben.
Man hat zunächst sein “home”-Projekt, kann aber auch Unterprojekte/Branches erstellen.
Dort konfiguriert man dann für welche Distros man Pakete bauen will, das kann man aber auch für jedes Paket einzeln nachjustieren.
Man legt nun ein Paket im Projekt an und checkt das (noch) leere Paketverzeichnis aus, die Bedienung mittels CLI-Client (nennt sich “osc”) erinnert ein wenig an SVN.
(Für manche Aufgaben, besonders die allgemeine Projektkonfiguration ist es allerdings zumindest anfangs einfacher das Webinterface zu verwenden.)
Nach dem Auschecken des leeren Pakets kann man seine Dateien im passenden Verzeichnis ablegen,die lokale Struktur ist
Hat man alles zusammen, für RPMs braucht man ein .spec (Bauvorschrift), die Quellen (tar.gz/bz2/xz/zip/etc.), ggf. Patches und eine .changes-Datei für den Paketchangelog, für .deb AFAIK eine .dsc (Bauvorschrift?), die Quellen, ggf. Patches und ..(? da bin ich jetzt überfragt, was man für debs noch so braucht).
Anschliessend kann man mittels des CLI-Clients einen lokalen Testbuild ausführen.
Was dann passiert ist Folgendes
Wenn das alles geklappt hat, kann man die Quelldateien für das Paket in den OBS einchecken, das Paket wird im OBS gebaut, signiert und sofern man will im eigenen Repo veröffentlicht.
Das (lokale) Bauen in einem chroot, welches eine minimale und standardisierte Buildumgebung enthält, kann man dann auch zumindest als sinnvolle Grundlage für reproduzierbare Build ansehen.
Die OBS-Infrastruktur macht da wohl etwas in die Richtung, ab und zu werden automatisch Rebuilds auf dem Server angestossen, wenn z.B. eine Abhängigkeit upgedated wurde (oder anders gesagt, wenn es ein Update für glibc gab, dann glüht der OBS
Was da genau passiert, weiß ich nicht wirklich, ich kann nur sagen, es kommt oft genug vor, daß man dann im Logfile des Build auf dem Server als eine der letzten Meldungen sinngemäß so etwas wie “Build does not differ from previous version, skipping publish” lesen kann.
Da RPM bei der Installation automatisch auch die (md5?)-Checksummen der im Paket enthaltenen Dateien mit in der RPM-Datenbank abspeichert, könnte ich mir vorstellen, daß dieser Vergleich herangezogen wird um festzustellen, ob sich wirklich etwas geändert hat.
Anonymous on :
1) Eure Diskussion mit Bezug auf Archlinux und deren radikale Umstellung /sbin in /usr/sbin und /bin in /usr/bin zu packen, hatte vor allem für einige Nutzer (die nicht genau aufgepasst bzw. die entsprechenden Hinweise gelesen hatten), vor allem auch die Folge, daß die Foren vollgestopft waren mit Threads der marke
“Hilfäää .. Kiste bootet nicht mehr!!11”
Das waren meist User, die ihr /usr in einer eigenen Partition hatten und wenn dann /sbin/init ein Symlink auf irgendwas in /usr (damals wohl auch schon /usr/lib/systemd/systemd, aber “ausnahmsweise ist daran nicht systemd schuld”
2) Zum Thema cpio, das findet bei RPMs sehr weite Verbeitung, denn RPMs werden als cpio verpackt und aktuell mit xz (lzma) komprimiert. Zusätzlich zum CPIO-Archiv für die Dateien kommen dann noch die Metadaten dazu (Name, Version, Requires/Conflicts/Recommends/etc., CHANGELOG, pre-/post-Scripte und ein Header) und ferig ist das RPM.
Jens Kubieziel on :
Anonymous on :
Ich hatte das mal so gelesen (ich schrieb ja, “gefährliches Halbwissen”, ich weiss nicht mehr so genau, wo das war), der Hauptgrund, warum ein Binary in /bin oder in /usr/bin (gleiches gilt für /sbin und /usr/sbin) landet, wäre die Frage “wird es für den ganz frühen Bootprozess gebraucht oder nicht?”, sprich brauche ich das Programm schon bevor das System “up” ist und sich ein Nutzer anmelden kann.
Das würde dann auch zu dem von mir geschilderten Problemen der User beim der Umstellung von Archlinux auf “alles nach /usr legen” passen.
Mal zwei Beispiele, wieso ich diese Begründung für nachvollziehbar halte.
Das Programm “/sbin/init” wird logischerweise im frühen Bootprozess gebraucht, ein “/bin/mount” auch, das liegt aber nicht in /sbin, weil es auch ggf. für Nutzer ausser root verfügbar sein muss (je nachdem, was in der /etc/fstab steht).
Allerdings, so ganz konsequent wurde das wohl nicht umgesetzt, /bin/ls oder /bin/ps braucht man wohl kaum zum Booten.
Was dann allerdings wiederum zur obigen These passen würde, die Aufspaltung in /usr/lib und /lib.
In /lib finden sich sehr viele Komponenten. die man dann doch gerne schon ganz früh im Bootprozess zur Verfügung haben will, z.B. glibc, Kernelmodule, Firmwaredateien für Kernelmodule etc.
Jens Kubieziel on :
Anonymous on :
Das Ganze klingt schon so plausibel, daß es eine “Verschwörungstheorie” sein *muss*.
Anonymous on :
Normalerweise ist das Sache des Paketierers im Paket festzulegen, was mit einer Konfigurationsdatei passieren soll.
Am Ende der Bauvorschrift (“spec”) gibt es den Abschnitt
mit (Überraschung) der Dateiliste der im Paket enthaltenen Dateien.
Will ich eine Datei als Konfigurationsdatei kennzeichnen, dann steht da nicht
sondern
Zusätzlich lässt sich festlegen, wie mit der Konfigurationsdatei umgegangen werden soll (dazu später noch was).
Jens hat das mit den Prüfsummen angesprochen, sofern die Konfigurationsdatei z.B. nicht angefasst wurde, geht rpm davon aus, daß sie überschrieben werden kann.
Wurde die Datei geändert (Usereingriff), dann gibt es soviel ich weiß (etwas dünneres Eis für mich) zwei Möglichkeiten.
1. Die alte Konfigurationsdatei wird durch die neue ersetzt, aber die alte Datei bleibt als Sicherungskopie mit der Endung “.rpmsave” immer noch vorhanden.
2. Die alte Konfigurationsdatei bleibt erhalten, die neue wird mit dem Suffix “.rpmnew” abgelegt.
In beiden Fällen meldet übrigens der Paketmanager, was passiert ist, in etwa so
oder so
Das Verhalten wie in 2. beschrieben, kann der Paketierer forcieren, indem er in der Dateiliste Folgendes einträgt:
Das Standardverhalten müsste -unter Vorbehalt, sicher bin ich mir da nicht 100%ig- Fall 1. sein.
Marco Bakera on :
Datenkanal on :