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, , cpan, , ... – Nur innerhalb ihres Bereichs – Oft ohne Root-Rechte möglich ● Distributionsspezifische – , 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 ● , , , , , , zypper, , 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 ( 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