Die Architektur

Bauen und ausliefern

Was auf dem Build Service liegt, wer welche Einstellung schreibt, und die Kette von einem Commit bis auf ein Gerät.

existiert

home:sm0x:smaragd:desktop

smaragd-release · patterns-smaragd · smaragd-branding · smaragd-defaults-desktop · smaragd-agama-product · smaragd-agama-branding · smaragd-bootnames · smaragd-bootwaechter · smaragd-updater · libsmaragd-supplements

Kein Erbe, deshalb billig. Sechs Theme-RPMs aus einer Quelle, per zypper auf jedem Tumbleweed installierbar.

existiert

home:sm0x:smaragd:images

Das Live-Abbild aus einer KIWI-Beschreibung und das Installationsmedium als Link auf den Agama-Installer — 39 Zeilen dazu, 5 weg, ein viertes Produktprofil neben openSUSE, Leap und SLE.

Aktuell: Build 8.2 vom 9. September 2026, 890 MB, Prüfsumme und Signatur geprüft.

Zeichnung

smaragd:testing · :release · :patched

Das Aggregat dessen, was gebaut ist; das Aggregat, auf das Nutzergeräte zeigen — erst nach grünem Prüfstand und menschlicher Freigabe; und das einzige Projekt mit Link auf die Basis, das leer startet. Jedes Paket darin wäre eine ADR und eine Schuld.

Der Namensraum smaragd: wird vor dem ersten öffentlichen ISO beantragt. Nichts hängt am Namen — Pfade und Vendor-Lock werden aus product.yaml erzeugt.

Eine Paketliste, drei Leser

image/packagelists/{minimal,desktop,toolbox}.list
     │
     │  packaging/patterns/generate.py
     ├──→ patterns-smaragd.spec   ← was ein Gerät installiert
     ├──→ image/smaragd.kiwi      nennt NUR die Patterns
     └──→ der Basiswächter        meldet wöchentlich, wenn
                                  ein Paket aus der Basis fällt

Die Unantastbaren

Diese Pakete werden niemals neu gebaut, gepatcht oder ersetzt. Der Torwächter bricht den Bau, wenn eines davon in einem smaragd-Projekt auftaucht:

shim  grub2-*-efi  kernel-*  *-kmp-*  dracut  mkinitrd
glibc  gcc-libs  systemd  dbus
Qt6*  KF6*  plasma*  mozilla-nss  openssl*  gnutls

Zwei Gründe: Signaturkette (oben) und Bauzeit (unten — ein glibc-Neubau zieht tausende Pakete nach sich). Erlaubt bleiben Konfiguration, Themes, ein danebenliegendes Paket, das eine Datei ablegt, und *-branding-smaragd mit Provides und Conflicts.

Wo Zustand liegt

Jede Einstellung hat genau einen Schreiber

Die wichtigste Tabelle der ganzen Architektur — weil YaST genau daran gestorben ist: Zwei Stellen schreiben dieselbe Datei, und die letzte gewinnt.

Was	Schreibt	Wohin
Unsere Standardwerte	das Paket `smaragd-defaults-desktop`	`/etc/xdg/*` — gehört uns
Desktop-Einstellungen des Nutzers	Plasma, der Nutzer	`~/.config/*` — gehört dem Nutzer
Aktive Ergänzungen	Ergänzungs-Oberfläche → zypper	Paketzustand, `/etc/zypp/repos.d/`
Fingerabdrücke	`fprintd`	`/var/lib/fprint/` — nie in einer Sicherung
Wiederherstellungsschlüssel	der Nutzer, beim Verschlüsseln	ausgedruckt oder in der Cloud — nie nur auf dem Gerät
Passwörter und Schlüssel	Anwendungen	KWallet, per PAM entsperrt
Verlauf	`smaragd-core`	`/var/lib/smaragd/history.db`
Wiederaufbau-Liste	die Sicherung, bei jedem Lauf	mit der Sicherung, wenige Kilobyte — sie ist die Wiederherstellung

Kein Einstellungsmodul schreibt Systemzustand direkt. Alles läuft über smaragd-core — das ist der Mechanismus gegen das YaST-Problem.

Die Freigabekette

Der Automat baut, die Maschine prüft, der Mensch nimmt ab

Der Product Owner liest keinen Code. Das ist keine Lücke, für die man sich entschuldigt — es ist eine Konstruktionsbedingung. Also verschiebt sich die Prüfung vom Diff auf das Verhalten.

läuft

Tor 1–3 und 6: der Torwächter

Bau mit Warnungen als Fehler, Lizenzköpfe, Geheimnis-Scanner, kein literaler Farbwert, kein unantastbares Paket, keine Handänderung in erzeugten Verzeichnissen, Werkzeugkasten vollständig, Kontrast nach WCAG AA. 38 Prüfungen, bei jedem Push, in einem Container, der dem Runner gleicht — seit dem 10. September 2026 auch dort grün.

einmal von Hand

Tor 4: der Prüfagent

Ein zweiter Lauf, getrennter Kontext, anderer Auftrag: „Finde, was hier schiefgehen kann.“ Er kennt die Begründung des Autors nicht. Am 9. September fand er in einer eigenen Sitzung, dass eine Vorprüfung etwas verlangte, das kein openSUSE erfüllt — und die Suite war grün, weil ihre Attrappe es zurückgab.

Phase 2

Tor 5: der Prüfstand

Sechs Kernszenarien auf einem eigenen Dauerläufer: Secure Boot, Installation mit TPM, Offline-Update, künstlicher Bootfehler mit Rückfall, Flatpak ohne Passwort, smaragd-verlassen. Rauchtest je PR, volle Suite je Merge, Kettentest wöchentlich, Dauerlauf monatlich.

Was der Mensch am Sonntag tut

Eigenschaften lesen — ist die Liste richtig und vollständig? Rechte-Diff ansehen — wird irgendwo mehr erlaubt als vorher? Ampeln ansehen. Prüferbericht lesen. Das ISO selbst benutzen. Abnehmen. Keiner dieser Schritte verlangt Programmierkenntnis, und die beiden, die tatsächlich Fehler finden, sind der erste und der fünfte.