TPA

Warum dieses Projekt?

Ein Meta-Paket ist ein leeres Paket: Es enthält keine eigenen Programme, sondern legt nur fest, welche anderen Pakete benötigt werden. Bei der Installation lädt APT diese Abhängigkeiten automatisch mit. So wird aus einer Liste einzelner Tools eine gemeinsam installierbare Softwareausstattung.

Wie es funktioniert

• Pakete erstellen: TPA erzeugt .deb-Dateien – das Installationsformat von Debian. Bei Meta-Paketen kann der direkte Build von der Beschreibung bis zur fertigen Paketquelle durchlaufen, ohne zusätzliche Arbeitsordner pro Paket.
• Paketquelle aufbauen: Aus den fertigen Paketen erstellt TPA die Verzeichnisse und Übersichten, die APT für Installation und Updates benötigt. Eine zusätzliche dauerhafte Paketdatenbank ist dafür nicht nötig.
• Herkunft überprüfbar machen: Digitale Signaturen mit GPG ermöglichen es APT, die Paketquelle zu prüfen. TPA läuft als eigenständiges Werkzeug; mein Dienst TPA.run nutzt es, um Paketquellen online bereitzustellen.

Eine gemeinsame Ausstattung für viele Geräte

Angenommen, du verwaltest eine ganze Flotte aus Entwicklungsrechnern und Servern. Statt auf jedem Gerät alle Tools einzeln zu installieren, definierst du zwei Meta-Pakete: workstation-dev für die Entwicklung und workstation-server für die Server.

Beide können ein gemeinsames Meta-Paket workstation-core voraussetzen, das beispielsweise gpg und curl mitbringt. workstation-dev ergänzt dann die Entwicklungswerkzeuge, workstation-server die benötigten Serverdienste. So beschreibst du die gemeinsame Grundausstattung einmal und ergänzt je nach Aufgabe die passenden Pakete.

Auf einem Entwicklungsrechner genügt dann sudo apt install workstation-dev, auf einem Server sudo apt install workstation-server. Voraussetzung ist, dass die entsprechende Paketquelle eingerichtet ist. APT installiert die jeweils benötigten Pakete samt gemeinsamer Basis.

Ändert sich die gewünschte Ausstattung, veröffentlichst du eine neue Version des Meta-Pakets. Beim Aktualisieren können die Geräte die neuen Abhängigkeiten übernehmen. Das hilft, viele Rechner auf eine gemeinsame Softwarebasis zu bringen. Identische Programmversionen oder Konfigurationen entstehen dadurch allerdings nicht automatisch; auch zusätzlich installierte Programme werden nicht von selbst entfernt.

Auch Einstellungen lassen sich als eigenes Debian-Paket bereitstellen: etwa ein Paket mit Konfigurationsdateien oder einem selbst entwickelten Tool, das die gewünschte Einrichtung übernimmt. TPA kann solche Pakete ebenfalls bauen. workstation-dev oder workstation-server können sie dann als Abhängigkeit einbinden. Das Meta-Paket legt fest, was installiert wird; das Konfigurationspaket oder Tool übernimmt die eigentlichen Einstellungen.

TPA ist also nicht auf leere Meta-Pakete beschränkt. Es kann auch Programme und Dateien verpacken, ist aber besonders für die schnelle Erstellung großer Meta-Paketbestände optimiert. Der unten gezeigte Benchmark bezieht sich auf diesen Spezialfall, nicht auf Pakete mit umfangreichem Dateiinhalt.

Weniger Zwischenkopien, schneller zum fertigen Paket

Normalerweise werden für jedes Paket zunächst Ordner und Dateien vorbereitet. Daraus entsteht eine Paketdatei, die anschließend noch einmal in die Paketquelle kopiert wird. Bei wenigen Paketen fällt das kaum auf – bei tausenden wiederholen sich diese Schritte entsprechend oft.

Der direkte Build von TPA bereitet die Paketbeschreibungen im Arbeitsspeicher auf und schreibt die fertigen Pakete direkt an ihren Zielort. Dieser In-RAM-Build vermeidet zusätzliche Arbeitsordner, Zwischenkopien und den Start eines externen Bauprogramms für jedes Paket. Die fertigen Dateien werden weiterhin gespeichert und anschließend zur Kontrolle erneut gelesen; die gesamte Paketquelle muss also nicht dauerhaft im RAM liegen.

Benchmark: 50.000 Meta-Pakete in rund 22,2 Sekunden

Im veröffentlichten Vergleich wurden 50.000 Meta-Pakete samt Paketquelle erstellt und geprüft. Der konventionelle Ablauf und Direct-RAM liefen jeweils dreimal. Das Diagramm zeigt den Median, also den mittleren der drei Zeitwerte jeder Variante.

Statt rund 134 Sekunden benötigte Direct-RAM rund 22 Sekunden. Das entspricht einem Vorsprung um den Faktor 6,01 beziehungsweise etwa 83 % weniger Wartezeit. Gerade wenn viele kleine Meta-Pakete regelmäßig neu entstehen, spart das wiederholte Vorbereiten und Kopieren deutlich Zeit.

Alle sechs Durchläufe bestanden die Prüfung sämtlicher 50.000 Paketarchive. Die unabhängig geprüften Inhalte stimmten überein: Paketangaben und Abhängigkeiten, vier Skripte samt Rechten, Eigentümerangaben und der leere Dateiinhalt. Zeitstempel und Kompression waren aus diesem Vergleich ausgenommen. Inhaltlich gleiche Pakete müssen also nicht Byte für Byte identische Archivdateien sein.

Gemessen wurde mit vier parallel arbeitenden Workern auf einem Ryzen 7 5800X unter Debian 13. Die Arbeitsdateien lagen auf tmpfs, einem Dateisystem im Arbeitsspeicher; ihre Belegung wurde zusätzlich stichprobenartig erfasst. Die Zeit umfasst das Erzeugen und Prüfen der Paketquelle. Signieren und die zusätzliche unabhängige Archivprüfung wurden nicht mitgemessen. Die Varianten verwendeten unterschiedliche Kompressionsverfahren: xz beziehungsweise gzip.

Auch der Wiederholungslauf lief nicht auf einem vollständig freigehaltenen Rechner: Zu Beginn war ein CPU-intensiver ccc-Prozess sichtbar, die aufgezeichnete Systemlast lag zwischen 4,3 und 11,3. Der erste, durch parallele Arbeit beeinflusste 50.000er-Lauf bleibt aus der dargestellten Auswertung heraus. Die Zahlen sind deshalb ein beobachteter Vergleich unter diesen Bedingungen, keine garantierte Laufzeit.

50.000 kleine Meta-Pakete sind ein Skalierungstest, kein repräsentativer Nachbau eines vollständigen Debian-Repositorys mit großen Programmpaketen. Der direkte Weg benötigte in diesem Lauf außerdem nicht weniger RAM. Frühere Messungen mit acht Workern bleiben getrennt. Der dauerhaft verlinkte englische Bericht enthält alle sechs Messungen, die Testumgebung und eine Anleitung zum Nachstellen.

Veröffentlichten Direct-RAM-Benchmark auf GitHub lesen (Englisch) →

Quellcode & Dokumentation

Quellcode und die verfügbare Projektdokumentation findest du auf GitHub. Dort stehen auch die Hinweise zum Bauen, zur Nutzung und zur Lizenz.