Skip to Content
Building OsTilpasset software fra kildekode-repositories

Tilpasset software fra kildekode-repositories

OpenFactory-opskrifter kan referere til et Git-repository som custom package-input på understøttede image-builders. Det er en supply-chain-følsom sti: repository, opløst revision, packaging-instruktioner, build-afhængigheder og det producerede pakke kræver alle gennemgang.

Support er mål-specifik. Source package-builds afvises for nogle builders, herunder nuværende Raspberry Pi- og Proxmox-stier. Bekræft tilgængelighed i den normaliserede opskrift og build-planen, før du lover at et pakke bliver produceret.

Opskriftens form

Custom package-posteringer ligger under os.custom_packages:

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

Skemaet accepterer et branch-navn, ikke et uforanderligt commit-felt. Ved en kontrolleret release: registrer den præcise commit, builden opløser, og gør den commit til en del af bevaret provenance. En bevægelig branch alene er ikke reproducerbar input.

Forbered repository

Den nuværende package-sti forventer native packaging-metadata, der passer til målet. Almindelige eksempler er en Debian-mappe debian/ eller en RPM-spec. Præcis builder-adfærd og understøttede målversioner kan ændre sig, så valider et minimalt pakke i det udrullede miljø i stedet for at stole på en statisk kompatibilitetstabel.

For Debian-packaging, gennemgå mindst:

  • debian/control for source/binary-identitet og afhængigheder;
  • debian/changelog for pakkeversionen;
  • debian/rules og andre eksekverbare maintainer-scripts;
  • installationsmanifester og systemd-enheder; og
  • licensering og indlejret materiale fra tredjepart.

For RPM-packaging, gennemgå spec’ens kilder, build-krav, scriptlets, filliste og licensmetadata.

Antag aldrig, at repository-ejerskab gør dets build-scripts sikre. Package-builds kører ikke-betroet kilde- og packaging-logik inden for build-infrastrukturens isolationsgrænse.

Andre package-styring

Native packages

Brug os.packages til pakker, der allerede leveres af den valgte distribution eller et eksplicit konfigureret repository:

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

Package overrides

os.package_overrides kan erklære intent add, remove eller replace:

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

En override beviser ikke, at dependency resolution fulgte den. Verificer det endelige pakkeinventar og absence/presence-assertions.

Yderligere repositories

os.extra_repos er et avanceret input. Tilføj ikke et usigneret HTTP-repository som i ældre eksempler. En godkendt repository-integration kræver HTTPS-transport, en fastlåst signing key, håndhævelse af signaturer, release-metadata passende til package manager, samt dokumenteret ejerskab og opdateringspolitik. Hvis de trust controls ikke kan repræsenteres af den nuværende builder, brug ikke repositoryet.

Acceptbevis

For hvert custom package, behold:

  • repository-URL og opløst commit;
  • gennemgang af kilde og erklæret licens;
  • build-miljø og dependency-snapshot;
  • build-logs og resulterende pakkenavn/version/arkitektur;
  • package digest og repository-signature-bevis hvor det gælder;
  • endeligt image-inventar, der viser pakken installeret;
  • service- eller executable-smoke-tests; og
  • adfærd ved fjernelse og opgradering.

En vellykket source package-fase er ikke nok. Image-builden kan senere fejle med at konsumere pakken, og et installeret pakke kan stadig være ubrugeligt.

Fejlfinding

  • Packaging-metadata afvist: valider det native pakke lokalt med samme distributionsrelease og arkitektur.
  • Build-afhængighed mangler: brug afhængigheder fra godkendte repositories for det mål; hent ikke vilkårlige binære filer stille i et maintainer-script.
  • Pakke mangler i imaget: sammenlign det producerede binære pakkenavn med normaliseret installationsanmodning og endeligt inventar.
  • Version ændrede sig ikke: opdater native versionsmetadata og bekræft, at den nye source-commit blev opløst.
  • Service fejlede: inspicer enheden, runtime-afhængigheder, rettigheder og gæstelogs; tilføj en adfærdsassertion før rebuild.
BasisimagesDesktop-images