Skip to content

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.

Shownotes

Folgen später

Trackbacks

Jens Kubieziel on : Jens Kubieziel via Twitter

Show preview
Wer kümmert sich um Updates + Abhängigkeiten von Software in #Linux? Paketmanager! Der @datenkanal zum Thema http://t.co/x9NYbEOhWU #debian

freak_out on : freak_out via Twitter

Show preview
Datenkanal 36: Paketmanager unter Linux http://t.co/OZA8AgPXH3

Jens Kubieziel on : Jens Kubieziel via Twitter

Show preview
Die Kommentare zum letzten @datenkanal bereichern die Sendung und sind sehr lesenswert: http://t.co/x9NYbEOhWU

Hackerei on : Hackerei via Twitter

Show preview
RT @qbi: Die Kommentare zum letzten @datenkanal bereichern die Sendung und sind sehr lesenswert: http://t.co/x9NYbEOhWU

Comments

Display comments as Linear | Threaded

Anonymous on :

Ein paar kurze Ergänzungen aus der “rpm”-Welt, das Ganze war -kein Vorwurf, da Ihr beide wohl eher aus dem Debian-Umfeld kommt- doch ein wenig Debianlastig.

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 :

Vielen Dank für deine Hinweise. Wir kommen beide aus der Debian-Welt und haben RPM-Systeme höchstens mal testweise installiert. Vielleicht müssen wir mal versuchen, einen RPM-Spezialist in die Sendung zu bekommen. :-)

Anonymous on :

Könnte man vielleicht wirklich machen, wobei ob das alleine eine ganze Sendung ergeben würde, keine Ahnung.

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 :

Du glaubst gar nicht, wie schnell zwei Stunden um sein können. Wir haben oft das Problem, dass wir wesentlich mehr vorbereitet haben als wir in der Sendung erzählen können. Insofern glaube ich schon, dass wir die Sendung voll bekommen.

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 :

Zumindest in Bezug auf das, was man “von aussen” als Ergebnis im Sinne von fertigen Paketen sehen kann, dürfte das Launchpad sehr nahe kommen.

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

CODE:
$HOME/osc/$PROJEKTNAME/$PAKETNAME


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.

CODE:
osc build $DISTRO $ARCHITEKTUR


Was dann passiert ist Folgendes
  • Es werden die benötigten Pakete für eine minimale. standardisierte Buildumgebung passend zu Distro/Architektur heruntergeladen und lokal zwischengespeichert
  • Es wird eine chroot-Umgebung aufgesetzt und in diese das Buildsystem installiert
  • Es wird ins Buildsystem gewechselt (chroot) und in dieser Umgebung der Build ausgeführt
  • Nach dem Build (sofern erfolgreich) laufen noch ein paar Tests durch und eine Zusammenfassung wird angezeigt

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 ;-)), allerdings wird das Endprodukt mit dem letzen Build verglichen.

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 :

Der “RPM-Bastler” hat gerade (beim zweiten Hören) noch ein paar Ergänzungen zu machen:

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” :-)) ist, dann knallt es eben beim Versuch “init” auszuführen ganz gewaltig (zumindest dann, wenn man nicht in der initial ramdisk schon dafür gesorgt hatte, daß /usr vor dem Aufruf von init gemountet wird).

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 :

Du hast natürlich recht. An den Punkt mit verschiedenen Partitionen und einer Zusammenlegung von /bin, /usr/bin etc. hatte ich in der Sendung nicht gedacht. Wobei sinnvollerweise könnte man dann alles von /usr/bin nach /bin werfen. Dann sollte sich das Problem in geringerem Ausmaß stellen. Außer halt bei Typen wie mir, die auf der Partition, wo /bin liegt zu wenig Platz haben.

Anonymous on :

Wobei mir da gerade noch etwas einfällt, aber das könnte gefährliches Halbwissen sein.

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 :

Schau dir mal die Mail auf der Busybox-ML an. Rob Landley berichtet dort von neuen Platten auf der ursprünglichen PDP11 und der resultierenden Trennung. Mir erscheint dies durchaus plausibel.

Anonymous on :

Danke für den Link, sehr informativ und nicht minder unterhaltsam.

Das Ganze klingt schon so plausibel, daß es eine “Verschwörungstheorie” sein *muss*.

:-D

Anonymous on :

Höre gerade die Folge 38, genauer den Abschnitt um rpm und die Sonderbehandlung bei Konfigurationsdateien, dazu noch ein wenig Senf von mir (so rein Ping-Pong-technisch gesehen :-)).

Normalerweise ist das Sache des Paketierers im Paket festzulegen, was mit einer Konfigurationsdatei passieren soll.

Am Ende der Bauvorschrift (“spec”) gibt es den Abschnitt
CODE:
%files

mit (Überraschung) der Dateiliste der im Paket enthaltenen Dateien.

Will ich eine Datei als Konfigurationsdatei kennzeichnen, dann steht da nicht

CODE:
/Pfad/Datei


sondern

CODE:
%config /Pfad/Datei


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

CODE:
additional rpm output<br /> file /etc/foobar created as /etc/foobar.rpmnew


oder so

CODE:
additional rpm output<br /> file /etc/foobar saved as<br /> /etc/foobar.rpmsave


Das Verhalten wie in 2. beschrieben, kann der Paketierer forcieren, indem er in der Dateiliste Folgendes einträgt:

CODE:
%config %noreplace /Pfad/Datei


Das Standardverhalten müsste -unter Vorbehalt, sicher bin ich mir da nicht 100%ig- Fall 1. sein.

Marco Bakera on :

Danke für die schöne Sendung. Es war mein Einstieg in euren Podcast und hat mir gut gefallen.

Datenkanal on :

Schön. Das freut uns. Ab Mitte/Ende Januar 2016 gehen wir wieder auf Sendung und werden hoffentlich einige interessante Sendungen produzieren.

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
BBCode format allowed
Form options
tweetbackcheck