Skip to Content
Building OsCustom Software aus Source-Repositories

Custom Software aus Source-Repositories

OpenFactory-Rezepte können auf unterstützten Image-Buildern ein Git-Repository als Custom-Package-Input referenzieren. Das ist ein supply-chain-sensibler Pfad: Repository, aufgelöste Revision, Packaging-Anweisungen, Build-Abhängigkeiten und erzeugtes Paket erfordern Review.

Support ist zielspezifisch. Source-Package-Builds werden für manche Builder abgelehnt, u. a. aktuelle Raspberry Pi- und Proxmox-Pfade. Verfügbarkeit im normalisierten Rezept und Build-Plan bestätigen, bevor Sie zusagen, dass ein Paket erzeugt wird.

Rezeptform

Custom-Package-Einträge liegen unter os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

Das Schema akzeptiert einen Branch-Namen, kein unveränderliches Commit-Feld. Für ein kontrolliertes Release den exakt vom Build aufgelösten Commit dokumentieren und diesen Commit zur retained Provenienz machen. Ein sich bewegender Branch allein ist kein reproduzierbarer Input.

Repository vorbereiten

Der aktuelle Package-Pfad erwartet native Packaging-Metadaten passend zum Ziel. Typische Beispiele sind ein Debian-debian/-Verzeichnis oder ein RPM-Spec. Konkretes Builder-Verhalten und unterstützte Target-Versionen können wechseln; validieren Sie ein minimales Paket in der ausgerollten Umgebung statt einer statischen Kompatibilitätstabelle.

Für Debian-Packaging mindestens prüfen:

  • debian/control für Source-/Binary-Identität und Abhängigkeiten;
  • debian/changelog für die Paketversion;
  • debian/rules und andere ausführbare Maintainer-Skripte;
  • Install-Manifeste und systemd-Units; und
  • Lizenzierung und gebündeltes Third-Party-Material.

Für RPM-Packaging Spec-Sources, Build-Requirements, Scriptlets, File-List und Lizenz-Metadaten prüfen.

Nehmen Sie nicht an, Repository-Ownership mache Build-Skripte sicher. Package-Builds führen nicht vertrauenswürdige Source- und Packaging-Logik innerhalb der Isolationsgrenze der Build-Infrastruktur aus.

Weitere Paket-Steuerung

Native Pakete

Nutzen Sie os.packages für Pakete aus der gewählten Distribution oder einem explizit konfigurierten Repository:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

Package Overrides

os.package_overrides kann add, remove oder replace deklarieren:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

Ein Override beweist nicht, dass die Abhängigkeitsauflösung ihm folgte. Finales Paketinventar und Presence/Absence-Assertions prüfen.

Zusätzliche Repositories

os.extra_repos ist ein fortgeschrittener Input. Fügen Sie kein unsigniertes HTTP-Repository wie in älteren Beispielen hinzu. Eine genehmigte Repository-Integration braucht HTTPS-Transport, gepinnten Signing Key, Signature Enforcement, Release-Metadaten passend zum Package Manager sowie dokumentierte Ownership und Update-Policy. Können diese Trust-Controls vom aktuellen Builder nicht dargestellt werden, nutzen Sie das Repository nicht.

Abnahme-Nachweis

Für jedes Custom Package behalten:

  • Repository-URL und aufgelösten Commit;
  • Source- und deklarierte Lizenz-Review;
  • Build-Umgebung und Dependency-Snapshot;
  • Build-Logs sowie resultierenden Paketnamen/Version/Architektur;
  • Paket-Digest und Repository-Signature-Nachweis, wo zutreffend;
  • finales Image-Inventar mit installiertem Paket;
  • Service- oder Executable-Smoke-Tests; und
  • Entfernungs- und Upgrade-Verhalten.

Eine erfolgreiche Source-Package-Stage reicht nicht. Der Image-Build kann das Paket später nicht konsumieren, und ein installiertes Paket kann trotzdem unbrauchbar sein.

Fehlerbehebung

  • Packaging-Metadaten abgelehnt: natives Paket lokal mit derselben Distributions-Release und Architektur validieren.
  • Build-Abhängigkeit fehlt: Abhängigkeiten aus genehmigten Repositories für dieses Ziel nutzen; keine willkürlichen Binaries in Maintainer-Skripten laden.
  • Paket fehlt im Image: erzeugten Binary-Paketnamen mit normalisierter Install-Anfrage und finalem Inventar vergleichen.
  • Version unverändert: native Versions-Metadaten aktualisieren und bestätigen, dass der neue Source-Commit aufgelöst wurde.
  • Service fehlgeschlagen: Unit, Runtime-Abhängigkeiten, Berechtigungen und Gast-Logs prüfen; Verhaltens-Assertion vor Rebuild hinzufügen.
Base ImagesDesktop-Images