Skip to Content
Building OsCustom software uit bronrepositories

Custom software uit bronrepositories

OpenFactory-recepten kunnen op ondersteunde image-builders een Git-repository als custom package-input refereren. Dit is een supply-chain-gevoelig pad: de repository, de opgeloste revisie, packaging-instructies, build-afhankelijkheden en het geproduceerde pakket vragen allemaal review.

Ondersteuning hangt af van het doel. Source-package-builds worden voor sommige builders geweigerd, waaronder de huidige Raspberry Pi- en Proxmox-paden. Bevestig beschikbaarheid in het genormaliseerde recept en het buildplan voordat u belooft dat er een pakket wordt geproduceerd.

Receptvorm

Custom package-vermeldingen staan onder os.custom_packages:

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

Het schema accepteert een branchnaam, geen onveranderlijk commit-veld. Voor een gecontroleerde release noteert u de exacte commit die de build oplost en neemt u die commit op in de bewaarde provenance. Alleen een bewegende branch is geen reproduceerbare input.

Bereid de repository voor

Het huidige package-pad verwacht native packaging-metadata die past bij het doel. Veelvoorkomende voorbeelden zijn een Debian-debian/-map of een RPM-spec. Concreet builder-gedrag en ondersteunde doelversies kunnen wijzigen; valideer daarom een minimaal pakket in de uitgerolde omgeving in plaats van op een statische compatibiliteitstabel te vertrouwen.

Voor Debian-packaging controleert u minstens:

  • debian/control voor source/binary-identiteit en afhankelijkheden;
  • debian/changelog voor de pakketversie;
  • debian/rules en andere uitvoerbare maintainer-scripts;
  • installatiemanifesten en systemd-units; en
  • licenties en meegeleverd materiaal van derden.

Voor RPM-packaging controleert u de sources in de spec, build-requirements, scriptlets, bestandslijst en licentiemetadata.

Ga nooit uit van veiligheid alleen omdat u de repository bezit. Package-builds voeren niet-vertrouwde source- en packaging-logica uit binnen de isolatiegrens van de build-infrastructuur.

Overige package-instellingen

Native packages

Gebruik os.packages voor pakketten die al door de gekozen distributie of een expliciet geconfigureerde repository worden geleverd:

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

Package overrides

os.package_overrides kan intentie add, remove of replace declareren:

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

Een override bewijst niet dat dependency resolution die heeft gevolgd. Controleer het uiteindelijke pakketinventaris en absence/presence-assertions.

Extra repositories

os.extra_repos is een geavanceerde input. Voeg geen ongetekende HTTP-repository toe zoals in oudere voorbeelden. Een goedgekeurde repository-integratie vereist HTTPS-transport, een vastgepinde signing key, handhaving van handtekeningen, release-metadata passend bij de package manager, plus gedocumenteerd eigendom en updatebeleid. Als die trust controls niet door de huidige builder kunnen worden weergegeven, gebruik de repository dan niet.

Acceptatiebewijs

Voor elk custom package bewaart u:

  • repository-URL en opgeloste commit;
  • review van broncode en gedeclareerde licentie;
  • build-omgeving en dependency-snapshot;
  • buildlogs en resulterende pakketnaam/versie/architectuur;
  • package digest en repository-signature-bewijs waar van toepassing;
  • definitief image-inventaris waar het pakket geïnstalleerd staat;
  • service- of executable-smoke-tests; en
  • gedrag bij verwijderen en upgraden.

Een geslaagde source-package-fase is niet genoeg. De image-build kan het pakket later niet consumeren, en een geïnstalleerd pakket kan alsnog onbruikbaar zijn.

Probleemoplossing

  • Packaging-metadata geweigerd: valideer het native pakket lokaal met dezelfde distributierelease en architectuur.
  • Build-afhankelijkheid ontbreekt: gebruik afhankelijkheden uit goedgekeurde repositories voor dat doel; haal geen willekeurige binaries stil op in een maintainer-script.
  • Pakket ontbreekt in de image: vergelijk de geproduceerde binary-pakketnaam met het genormaliseerde installatieverzoek en het uiteindelijke inventaris.
  • Versie niet gewijzigd: werk native versiemetadata bij en bevestig dat de nieuwe source-commit is opgelost.
  • Service mislukt: inspecteer de unit, runtime-afhankelijkheden, rechten en gastlogs; voeg een gedragsassertie toe vóór een rebuild.
BasisimagesDesktopimages