Soll ich's Ihnen einpacken?
Warum Paketverwaltung auch im App-Store-Zeitalter zeitgemäß ist
Volker Fröhlich Kevin Kofler
Welche Probleme lösen Paketverwaltungen?
● Programme – Installieren – Deinstallieren – Aktualisieren ● Kontrolle darüber, was wo ist ● Berücksichtigt – Abhängigkeiten/Konflikte – Programmspezifisches Wissen
Welche Systeme gibt es?
● Ökosystemspezifische – Gem, pip, cpan, pear, ... – Nur innerhalb ihres Bereichs – Oft ohne Root-Rechte möglich ● Distributionsspezifische – DPKG, RPM, Pacman, ... – Auch portiert (AIX, Solaris, ...)
Was ist ein Paket?
● Spezielle Datei, deren Inhalt die Paketverwaltung versteht ● Beinhaltet Programme, Daten, Dokumentation, Liste mit unmittelbaren Abhängigkeiten, Skripte, Prüfsummen, Signaturen und andere Metadaten, ... ● Paketmanager führt Datenbank
Historischer Exkurs
● RPP, PMS, PM (1994) – „Pristine sources“ – Mehrere Architekturen ● RPM (1996) – http://www.rpm.org/max-rpm/s1-intro-to-rpm- package-management-how.html ● DPKG (1994)
Frontends und Zwischenschichten I
● Effektives Auflösen von Abhängigkeiten ● Akquise aus verschiedenen Quellen – Repositories – Direkt
Frontends und Zwischenschichten II
● Basis für grafische Anwendungen ● Konfigurationsoberfläche ● apt, synaptic, apper, up2date, yum, dnf, zypper, urpmi, pacman, PackageKit, ...
Welche Paketverwaltung ist besser?
● Entscheidung fällt mit Distribution – Andere Paketverwaltung möglich – Alien ● Lösen die selben Probleme
● Implementierung im Detail sehr verschieden – Fähigkeiten nicht deckungsgleich – Rosetta-Stein – Sprache für Bauanleitungen
Aber mit xy geht das viel besser I
● Händisch ● Installationsskripts – Alles ist möglich, Root nötig ● Konfigurationsmanagement missbrauchen
Aber mit xy geht das viel besser II
● Checkouts – Bei eigenen Entwicklungen oder in Sonderfällen ● Container/App-Store ● Bereichweise Systeme ● BSD Ports/Emerge
Einschränkungen I
● Hostspezifische Konfiguration --> Konfigurationsverwaltung ● Jemand muss die Arbeit machen! – Zerspragelung zwischen Distributionen – Oft Voluntärsarbeit, außerdem Regeln – Build-Optionen/Linking
Einschränkungen II
● Austauschbarkeit zwischen Distributionen – If-Klauseln – Paket-Namen – Unterschiedliche Unterpaketierung – Unterschiedliche Regeln – Soname-Versionen ● Verschiedene Versionen parallel – Chroot – Software Collections
Woher kommen Pakete?
● Distribution ● Distributionsnahe Ergänzungen ● Entwickler/Hersteller ● Buildsysteme (OBS, PPA, COPR, ...) ● Selbst gestrickt
Mehrwert von Distributionspaketen
● Vertrauen ● Regeln – Update- und Upgrade-Politik – Eingeschränkter Personenkreis aber oft Teilnahmemöglichkeit – Bundles
● Sicherheitsupdates – Lizenzen – Frei von unerwarteten Konflikten
Unangenehme Überraschungen
● IBM TSM – Symlink macht funktionsunfähig (Scriptlet) ● Brother-Treiber – Manipulierte Systemdateien ● Sun Java – Konflikte mit Distributionspaketen ● Logstash – Deinstallation löscht Benutzer und verwaist Daten
Pakete selber machen?
● Rebuilds
● Bauanleitung schreiben – Wenige Stunden Einarbeitungszeit können genügen ● Für Unternehmen, aber auch privat
● Mit Anderen teilen (Regeln!) ● Auch Entwickler profitieren – Reichweite – Qualitätskontrolle
Ausblick: Neues in RPM
● Größere Pakete (kein CPIO mehr) ● Anderes Datenbanksystem
● Schwache Abhängigkeiten („Suggests“) ● Boolesche Abhängigkeiten (noch nicht fertig) – A oder B oder (C und D und nicht E)
DPKG- und RPM-Tutorium
● DPKG-Tutorium – Sem 4.02, 11:00, einstündig ● RPM-Tutorium – Anatomie einer Spec-Datei – Einführung anhand vorbereiteter Beispiele – Praktische und unabdingbare Werkzeuge – Sem 4.02, 15:00, einstündig