IT-Sicherheit Software-Entwicklung Schulungen Über Uns Blog

embedded

28.10.2025

Dieser Beitrag wurde von einem LLM aus dem Englischen ins Deutsche übersetzt. Zum englischen Original

Offenlegung: Als langjähriger Nutzer von KAS und Contributor sind meine persönlichen Ansichten hier naturgemäß nicht neutral. Die technischen Fakten habe ich aber so korrekt und objektiv wie möglich gehalten.

Die sich wandelnde Landschaft des Yocto-Projekt-Setups: bitbake-setup vs. KAS

Wer schon einmal mit Yocto eine eigene Linux-Distribution erstellt hat, dem ist vermutlich aufgefallen, dass das Yocto-Projekt selbst keine standardisierte Methode für den allerersten Schritt bietet: alle benötigten Layer zu holen und die initiale Build-Konfiguration anzulegen. Seit 2017 füllt das Tool KAS diese Lücke. Heute, im Jahr 2025, hat KAS eine beachtliche Nutzerbasis und eine lebendige Community. Dennoch ist es weder offizieller Bestandteil des Yocto-Projekts noch das offiziell empfohlene Tool für das Projekt-Setup. Seit 2024 entwickelt das Yocto-Projekt ein eigenes Tool: bitbake-setup. Jetzt, Ende 2025, nimmt dieses neue Tool Gestalt an.

Als Linux-Berater erhalten wir häufig Fragen von Kunden zum Status und zur zukünftigen Richtung des Yocto-Projekt-Setups. Besonders seit bitbake-setup verfügbar ist, werden wir gefragt, was aus KAS wird, was von bitbake-setup zu erwarten ist und so weiter. Dieser Blogbeitrag fasst die aktuelle Situation zusammen und klärt die wichtigsten Unterschiede und Konsequenzen beim Einsatz von KAS gegenüber bitbake-setup.

KAS: Ursprünge und ein kurzer Überblick

Vor dem Aufkommen von KAS¹ (bairisch für Käse) verwalteten Yocto-Nutzer ihre Layer-Abhängigkeiten typischerweise entweder mit git submodules oder mit dem Tool repo². Dieser Ansatz stützte sich oft auf eine Sammlung von Shell-Skripten, um grundlegende Konfigurationsdateien wie bblayers.conf und local.conf zu erzeugen. Dieser Prozess war häufig umständlich und sehr fehleranfällig.

Ingenieure bei Siemens erkannten diese fehlende Standardisierung als Risiko für die Qualität ihrer Build-Infrastruktur und suchten nach einer Lösung. Aus dieser Arbeit entstanden die ersten Konzepte hinter KAS. Das Kernprinzip von KAS ist, ein Yocto-Projekt in einer YAML-Konfigurationsdatei zu beschreiben, um deterministische Builds zu ermöglichen. Das Ziel ist einfach: Egal wo der Build läuft, das Ergebnis soll identisch sein. KAS kontrolliert die Build-Umgebung sorgfältig und stellt sicher, dass keine Umgebungsvariablen des Host-Systems in den Build gelangen, sofern sie nicht explizit in der KAS-Konfigurationsdatei angegeben sind. Entscheidend ist: KAS arbeitet als externes Tool mit Yocto zusammen. Es verpackt den Standard-Yocto-Prozess in eine deterministische Umgebung und erzeugt alle nötigen Konfigurationsdateien, aber Yocto muss von KAS nichts wissen.

Zusätzlich zur Kernfunktionalität bietet KAS ein Wrapper-Skript, kas-container, mit dem Entwickler das gesamte Projekt-Setup und den Build in einem Container mit Docker oder Podman ausführen können. Diese Containerisierung bietet eine hervorragende Isolation vom Host-System. Standardmäßig verwendet der KAS-Build-Container eine minimale Debian-Linux-Installation, in der nur die vom Yocto-Projekt zwingend benötigten Host-Abhängigkeiten installiert sind. So läuft jeder Build in einer vollständig deterministischen Umgebung, was das Versprechen reproduzierbarer Ergebnisse von KAS weiter stärkt.

Hier ein Beispiel einer typischen KAS-Konfigurationsdatei:

header:
  version: 14
machine: raspberrypi5
distro: poky
target: core-image-minimal
repos:
  poky:
    url: "https://git.yoctoproject.org/git/poky"
    commit: d0b46a6624ec9c61c47270745dd0b2d5abbe6ac1 # walnascar-5.2.4
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:
  meta-raspberry:
    url: "https://git.yoctoproject.org/meta-raspberrypi"
    commit: 5c540d5447fba8b652c8778af30e605242df650c # walnascar as of 23.10.2025
local_conf_header:
  sstate-cdn: |
     BB_HASHSERVE_UPSTREAM = 'wss://hashserv.yoctoproject.org/ws'
     SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
  rpi: |
     EXTRA_IMAGE_FEATURES = "ssh-server-openssh"
     LICENSE_FLAGS_ACCEPTED = "synaptics-killswitch"
     INHERIT += "rm_work"

Diese Datei beschreibt:

Welche Repositories (Layer) geholt werden und welcher exakte git-Commit zu verwenden ist.
Die Standardwerte für Machine, Distro und Ziel-Image des Builds.
Zusätzliche Variablen, die an die erzeugte local.conf angehängt werden.

Um das Projekt zu bauen, führen Sie den Befehl kas build rpi.yml aus. Soll der gesamte Prozess für maximale Host-Isolation in einem Container laufen, verwenden Sie den Wrapper: kas-container build rpi.yml.

Beim Ausführen von KAS passiert Folgendes:

Alle aufgeführten Repositories werden ausgecheckt.
Die Datei bblayers.conf wird erzeugt.
Die Datei local.conf wird erzeugt.
Der eigentliche Build-Befehl wird ausgeführt, hier bitbake -c build core-image-minimal.

Bei Verwendung von kas-container läuft KAS vollständig im Container. Das Host-System benötigt nur das Shell-Skript kas-container und entweder Docker oder Podman.

Über Projekt-Setup und Build hinaus bietet KAS diverse weitere Unterbefehle, die die Yocto-Entwicklung erleichtern. Die wichtigsten sind:

shell: Öffnet eine Shell in der bereinigten Build-Umgebung, nützlich zum Debuggen oder für eigene bitbake-Befehle.
menu: Bietet eine interaktive Oberfläche, um das Projekt zu konfigurieren und Build-Variablen zu setzen.
diff: Vergleicht zwei KAS-Konfigurationsdateien und zeigt das git-Log jedes referenzierten Repositories.
lock: Dient der Absicherung der Lieferkette, vergleichbar mit dem Lock-File-Mechanismus von Go, Cargo oder Node.js.

Mehr Details zu KAS finden Sie in der Dokumentation oder in diesem Vortrag von Jan Kiszka.

bitbake-setup: Die offizielle Lösung des Yocto-Projekts

Obwohl KAS permissiv unter der MIT-Lizenz steht und seine Entwickler wiederholt ihre Bereitschaft erklärt haben, KAS eng in das Yocto-Projekt zu integrieren, kam es nie dazu.³ ⁴ Yocto-Entwickler vertraten früh die Position, dass ein Setup-Tool wie KAS ein integrierter Bestandteil von bitbake sein sollte und kein eigenständiges Projekt. Ein Argument für ein solches Tool als Teil von bitbake ist, dass sich der Fetch-Code von bitbake wiederverwenden lässt, statt wie KAS derzeit git-Befehle direkt auszuführen. Diese Position führte direkt zur Entwicklung von bitbake-setup.

Wie der Name vermuten lässt, liegt bitbake-setup direkt im bitbake-Repository. Der allererste Schritt, um ein Yocto-System mit diesem Tool aufzusetzen und zu bauen, ist daher das Klonen des bitbake-git-Repositories selbst.

Ein typischer bitbake-setup-Workflow sieht so aus:

git clone -b master-next https://git.openembedded.org/bitbake
bitbake/bin/bitbake-setup init rpi.conf.json
. /path/to/your/builddir/init-build-env
bitbake core-image-minimal

Lässt man beim Aufruf von bitbake-setup init den Parameter weg, verwendet das Tool eine Standardkonfiguration. Typischerweise übergeben Sie aber den Namen, einen Pfad oder eine URL zu Ihrer Konfiguration.

Hier ein Beispiel einer einfachen JSON-Konfigurationsdatei für bitbake-setup:

{
  "description": "Raspberry Pi base config",
  "sources": {
    "bitbake": {
      "git-remote": {
        "remotes": {
          "origin": {
            "uri": "git://git.openembedded.org/bitbake"
          }
        },
        "rev": "master"
      },
      "path": "bitbake"
    },
    "openembedded-core": {
      "git-remote": {
        "remotes": {
          "origin": {
            "uri": "git://git.openembedded.org/openembedded-core"
          }
        },
        "rev": "master"
      },
      "path": "openembedded-core"
    },
    "meta-yocto": {
      "git-remote": {
        "remotes": {
          "origin": {
            "uri": "git://git.yoctoproject.org/meta-yocto"
          }
        },
        "rev": "master"
      },
      "path": "meta-yocto"
    },
    "meta-raspberrypi": {
      "git-remote": {
        "remotes": {
          "origin": {
            "uri": "git://git.yoctoproject.org/meta-raspberrypi"
          }
        },
        "rev": "master"
      },
      "path": "meta-raspberrypi"
    }
  },
  "bitbake-setup": {
    "configurations": [
      {
        "name": "poky",
        "description": "Poky reference distro build",
        "bb-layers": [
          "openembedded-core/meta",
          "meta-yocto/meta-yocto-bsp",
          "meta-yocto/meta-poky",
          "meta-raspberrypi"
        ],
        "oe-fragments": [
          "core/yocto/sstate-mirror-cdn"
        ],
        "oe-fragments-one-of": {
          "machine": {
            "description": "Available target machines",
            "options": [
              "machine/raspberrypi4",
              "machine/raspberrypi4-64",
              "machine/raspberrypi5"
            ]
          },
          "distro": {
            "description": "Available distributions",
            "options": [
              "distro/poky",
              "distro/poky-tiny"
            ]
          }
        }
      }
    ]
  },
  "version": "1.0"
}

Die Konfigurationsdatei definiert die zentralen Projektparameter, vor allem:

Welche Repositories (Layer) geholt werden.
Die verfügbaren Konfigurationen, hier Distributionen (DISTRO) und Machines (MACHINE).

Wie der Befehl kas menu kann bitbake-setup den Nutzer nach Konfigurationsentscheidungen fragen. Es bietet zum Beispiel, je nach geladener Konfiguration, mehrere Optionen für die gewünschte Machine und Distribution an. Die Benutzeroberfläche unterscheidet sich jedoch: KAS verwendet ein Kconfig-Menü als Text User Interface (TUI), bitbake-setup stellt Fragen und liest die Eingaben direkt über die Konsole ein.

Beispielausgabe von bitbake-setup beim Stellen der Fragen:

Selecting the only available bitbake configuration poky

Available target machines:
0. machine/raspberrypi4
1. machine/raspberrypi4-64
2. machine/raspberrypi5

Please select one of the above options by its number:
2

Available distributions:
0. distro/poky
1. distro/poky-tiny

Please select one of the above options by its number:
0

bitbake-setup verwaltet ein Top-Level-Verzeichnis, standardmäßig ~/bitbake-builds/. Dieses Verzeichnis enthält gemeinsam genutzte Ressourcen, darunter einen Download-Ordner, globale Einstellungen, Build-Konfigurationen und die initialisierten Yocto-Projekte. Wenn Sie mehrere Projekte mit bitbake-setup aufsetzen, teilen sie sich automatisch den Download-Ordner, weil bitbake-setup die Variable DL_DIR vorkonfiguriert. Außerdem nutzt bitbake-setup eine Registry zum Ablegen von Build-Konfigurationen. Die Standard-Registry liegt im bitbake-Repository, Sie können aber eine eigene definieren.

Um zum Beispiel eine neue Standard-Registry zu setzen, führen Sie bitbake-setup settings set default registry /path/to/my/bbregistry aus.

Nachdem Sie Ihre *.conf.json-Dateien in /path/to/my/bbregistry/configurations/ abgelegt haben, erkennen Befehle wie bitbake-setup list und bitbake-setup init diese.

$ bitbake-setup list
Loading settings from
    /home/bobthebuilder/bitbake-builds/settings.conf

Bitbake-setup is using /home/bobthebuilder/bitbake-builds as top directory ("bitbake-setup settings --help" shows how to change it).


Available configurations:
rpi     Raspberry Pi base config
base    A Yocto base configuration with options
xxx     Just testing

Run 'init' with one of the above configuration identifiers to set up a build.

Übergeben Sie bitbake-setup init also einen Konfigurationsnamen statt eines Dateinamens oder einer URL, sucht es die Konfiguration in der Registry.

Die Eingliederung von bitbake-setup in das bitbake-Repository hat erhebliche Auswirkungen darauf, wie Yocto-Projekte geholt werden. Zur Erinnerung: Das Poky-Repository diente traditionell als offizielles Referenzsystem und bündelte drei Kernkomponenten: bitbake, meta-yocto und openembedded-core. Da bitbake-setup verlangt, zuerst das eigenständige bitbake-Repository zu klonen, verliert das monolithische Poky-Repository seine historische Rolle. Nutzer können openembedded-core und meta-yocto nun einzeln neben bitbake holen. Folglich wird das Poky-Repository für zukünftige Yocto-Releases keine Updates mehr erhalten, Nutzern wird geraten, die Repositories einzeln zu holen.

Wie sich diese Änderung auf ein KAS-basiertes Projekt anwenden lässt, zeigt diese Änderung: https://github.com/mendersoftware/meta-mender-community/commit/f82d2d4a9ebc79ac3e88e6388609e4ec8e49a7e6.

Mehr Details zu bitbake-setup finden Sie in diesen zwei Vorträgen von Alexander Kanavin.

bitbake-setup und KAS im Vergleich

Der Vergleich dieser beiden Tools ist komplexer, als man zunächst erwarten würde. KAS und bitbake-setup haben unterschiedliche Ursprünge. KAS kommt im Grunde von Nutzern für Nutzer, während bitbake-setup die Perspektive der Yocto-Entwickler widerspiegelt. Die Yocto-Entwickler nutzten dieses Tool als Gelegenheit, lange aufgeschobene Aufgaben umzusetzen: das Entflechten des Poky-Repositories, die Einführung von Konfigurations-Fragmenten und ein Setup-Tool, das eng mit bitbake gekoppelt ist.

Ein zentraler technischer Unterschied zu KAS ist, dass bitbake-setup JSON als Konfigurationsformat verwendet, nicht YAML. JSON ist als Serialisierungsformat hervorragend, bringt aber für von Menschen editierte Konfigurationsdateien zwei wesentliche Einschränkungen mit:

JSON unterstützt keine Kommentare, was die Dokumentation erschwert.
Es erlaubt keine nachgestellten Kommata, was bei manuellen Änderungen zu Parser-Fehlern führen kann.

Wir bei der sigma star gmbh halten JSON daher für weniger geeignet für nutzerseitige Konfigurationsdateien.

Ein weiterer Unterschied in der Philosophie ist der Umgang mit der Datei local.conf. KAS befüllt die local.conf automatisch anhand der Einstellungen aus seiner YAML-Konfiguration. bitbake-setup befüllt Ihre local.conf nicht automatisch. Die Begründung: local.conf soll nur nutzerspezifische Einstellungen und Overrides enthalten und nicht mit automatisch erzeugtem Inhalt verunreinigt werden.

Das obige KAS-Beispiel würde etwa eine local.conf wie diese ergeben:

# rpi
EXTRA_IMAGE_FEATURES = "ssh-server-openssh"
LICENSE_FLAGS_ACCEPTED = "synaptics-killswitch"
INHERIT += "rm_work"

# sstate-cdn
BB_HASHSERVE_UPSTREAM = 'wss://hashserv.yoctoproject.org/ws'
SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"

MACHINE ??= "raspberrypi5"
DISTRO ??= "poky"
BBMULTICONFIG ?= ""

Im Gegensatz dazu die von bitbake-setup erzeugte local.conf:

#
# This file is intended for local configuration tweaks.
#
# If you would like to publish and share changes made to this file,
# it is recommended to put them into a distro config, or to create
# layer fragments from changes made here.
#

Da bitbake-setup zwar die Auswahl von Distribution und Machine erlaubt, aber die local.conf nicht befüllt, haben die Yocto-Entwickler ein generischeres Konzept eingeführt: Layer-Fragmente. Layer-Fragmente sind Dateien, die Variablen und ihre zugehörigen Werte enthalten. Sie wählen diese Dateien beim Projekt-Setup aus, und das System fügt ihren Inhalt direkt in den globalen Variablenbereich ein. Die Fragment-Auswahl nutzt die neue Datei toolcfg.conf und die Variable OE_FRAGMENTS. In unserem Beispiel zieht das System etwa immer core/yocto/sstate-mirror-cdn.conf heran, je nach Auswahl des Nutzers zusätzlich distro/poky.conf plus machine/raspberrypi5.conf.

toolcfg.conf:

OE_FRAGMENTS += "core/yocto/sstate-mirror-cdn distro/poky machine/raspberrypi5"

Auch die Konfiguration weiterer Einstellungen, etwa des Pfads zum Download-Verzeichnis (DL_DIR), unterscheidet sich. KAS setzt DL_DIR als Umgebungsvariable und fügt sie zu BB_ENV_PASSTHROUGH_ADDITIONS hinzu, sodass bitbake den DL_DIR-Wert aus der Umgebung übernimmt. bitbake-setup hingegen injiziert die Variable DL_DIR direkt in den Parser-Cache des bitbake-Codes.

Wie erwähnt verwenden bitbake-setup und KAS unterschiedliche Konfigurationsformate. Sie gehen mit diesen Konfigurationen auch unterschiedlich um. bitbake-setup verwendet strikt eine einzige Konfigurationsdatei. KAS bietet dagegen Mechanismen, um mehrere Konfigurationsdateien einzubinden oder zu schichten. Das geht entweder über die Eigenschaft includes in einer Konfigurationsdatei oder direkt auf der Kommandozeile, z. B. kas build rpi.yml:sigmastar-settings.yml. Diese Schichtung ist nützlich, um große, komplexe Build-Konfigurationen zu pflegen, bei denen verschiedene Yocto-Setups viele Einstellungen teilen. Sie erlaubt auch das Überschreiben einzelner Werte, etwa kundenspezifischer Einstellungen (z. B. URLs interner git-Repositories). Bei der sigma star gmbh nutzen wir diesen Mechanismus häufig, um kundenspezifische Einstellungen zu überschreiben, etwa URLs interner git-Repositories. Das ist zum Beispiel nötig, wenn kein direkter Zugriff auf das interne Netzwerk eines Kunden besteht und wir einen Mirror seiner git-Repos pflegen müssen. Für neugierige Leser: Dieses git-Repository zeigt eine nicht triviale KAS-Konfiguration, wie sie bei Siemens im Einsatz ist: https://github.com/siemens/meta-iot2050/.

Ein weiterer entscheidender Unterschied zu KAS ist, dass bitbake-setup keinerlei Host-Isolation vornimmt. Es checkt Quellen aus und konfiguriert Yocto, überlässt es aber dem Nutzer, die Build-Umgebung einzubinden und den gewünschten bitbake-Befehl auszuführen. Das Yocto-Projekt hat seine Widerstandsfähigkeit gegen Host-Kontamination in den letzten Jahren zwar deutlich verbessert, Probleme können aber weiterhin auftreten. Für Projekte, bei denen Reproduzierbarkeit Priorität hat, bleibt eine günstige containerbasierte Isolation ein wertvoller Schutz. Wir erwarten allerdings, dass Unterstützung für containerisierte Builds, wie sie kas-container bietet, irgendwann kommt. Priorität scheint das jedoch nicht zu haben⁵.

Und schließlich: Da sich bitbake-setup in einem frühen Entwicklungsstadium befindet, fehlt derzeit eine robuste Fehlerbehandlung. Bei Fehlern, etwa semantisch falschen Konfigurationen oder nicht erreichbaren Netzwerkressourcen, können Nutzer auf unbehandelte Python-Exceptions stoßen. Ich bin aber optimistisch, dass sich das in naher Zukunft bessert.

Zusammenfassung

Im Kern teilen bitbake-setup und KAS viele Funktionen, gehen sie aber unterschiedlich an. Der größte Unterschied ist, dass bitbake-setup tief in Yocto integriert ist, KAS dagegen nicht. bitbake-setup steckt noch in einem frühen Entwicklungsstadium, weitere Funktionen und Änderungen sind also zu erwarten. Wir gehen davon aus, dass bitbake-setup in den kommenden Jahren eine beträchtliche Nutzerbasis gewinnt, besonders sobald es in den offiziellen Yocto-Materialien dokumentiert ist. Stand heute ist KAS ausgereifter und funktionsreicher als bitbake-setup, daher werden wir KAS weiterhin allen unseren Kunden empfehlen. KAS bleibt funktionsfähig, egal in welche Richtung sich bitbake-setup entwickelt, weil es keine Anpassungen in Yocto benötigt.

Wir glauben, dass KAS und bitbake-setup voneinander profitieren können. Ein denkbares Szenario ist, dass bitbake-setup als Plugin aus KAS heraus nutzbar wird, um alle Layer zu holen und einzurichten, während KAS den Build des Projekts mit nur einem Befehl und einer einfachen Konfigurationsdatei ermöglicht. Wir erwarten außerdem, dass KAS früher oder später Layer-Fragmente nutzen wird.

Aus Sicht der Nutzer wirkt das leider wie eine verpasste Chance zur Zusammenarbeit. Hoffentlich werden auf lange Sicht sowohl die Hintergründe als auch der beiderseitige Nutzen sichtbar.