Skip to Content
Building OsTilpasset programvare fra kildekoderepositorier

Tilpasset programvare fra kildekoderepositorier

OpenFactory-oppskrifter kan referere til et Git-repositorium som custom package-input på støttede image-buildere. Dette er en supply-chain-følsom sti: repositoriet, løst revisjon, packaging-instruksjoner, build-avhengigheter og den produserte pakken krever alle gjennomgang.

Støtte er målspesifikk. Source package-bygg avvises for noen buildere, inkludert nåværende Raspberry Pi- og Proxmox-stier. Bekreft tilgjengelighet i den normaliserte oppskriften og byggeplanen før du lover at en pakke blir produsert.

Oppskriftsform

Custom package-poster ligger under os.custom_packages:

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

Skjemaet aksepterer et branch-navn, ikke et uforanderlig commit-felt. For en kontrollert release: registrer nøyaktig commit som bygget løser, og gjør den commiten til en del av bevart provenance. En bevegelig branch alene er ikke reproducerbar input.

Forbered repositoriet

Den nåværende package-stien forventer native packaging-metadata som passer til målet. Vanlige eksempler er en Debian-mappe debian/ eller en RPM-spec. Nøyaktig builder-atferd og støttede målversjoner kan endre seg, så valider en minimal pakke i det utrullede miljøet i stedet for å stole på en statisk kompatibilitetstabell.

For Debian-packaging, gå gjennom minst:

  • debian/control for source/binary-identitet og avhengigheter;
  • debian/changelog for pakkeversjonen;
  • debian/rules og andre kjørbare maintainer-skript;
  • installasjonsmanifester og systemd-enheter; og
  • lisensiering og inkludert materiale fra tredjepart.

For RPM-packaging, gå gjennom spec-ens kilder, build-krav, scriptlets, filliste og lisensmetadata.

Anta aldri at eierskap til repositoriet gjør byggeskriptene trygge. Package-bygg kjører ikke-betrodd kilde- og packaging-logikk innenfor isolasjonsgrensen til build-infrastrukturen.

Annen package-styring

Native packages

Bruk os.packages for pakker som allerede leveres av valgt distribusjon eller et eksplisitt konfigurert repositorium:

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

Package overrides

os.package_overrides kan deklarere intensjon 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. Verifiser endelig pakkeinventar og absence/presence-assertions.

Ekstra repositorier

os.extra_repos er et avansert input. Ikke legg til et usignert HTTP-repositorium som i eldre eksempler. En godkjent repository-integrasjon krever HTTPS-transport, en festet signing key, håndheving av signaturer, release-metadata passende for package manager, samt dokumentert eierskap og oppdateringspolicy. Hvis de trust controls ikke kan representeres av nåværende builder, ikke bruk repositoriet.

Akseptbevis

For hver custom package, behold:

  • repository-URL og løst commit;
  • gjennomgang av kilde og erklært lisens;
  • build-miljø og dependency-snapshot;
  • build-logger og resulterende pakkenavn/versjon/arkitektur;
  • package digest og repository-signature-bevis der det gjelder;
  • endelig image-inventar som viser pakken installert;
  • service- eller executable-smoke-tester; og
  • oppførsel ved fjerning og oppgradering.

En vellykket source package-fase er ikke nok. Image-bygget kan senere mislykkes med å konsumere pakken, og en installert pakke kan fortsatt være ubrukelig.

Feilsøking

  • Packaging-metadata avvist: valider den native pakken lokalt med samme distribusjonsrelease og arkitektur.
  • Build-avhengighet mangler: bruk avhengigheter fra godkjente repositorier for det målet; ikke hent vilkårlige binærfiler stille i et maintainer-skript.
  • Pakke mangler i imaget: sammenlign det produserte binære pakkenavnet med normalisert installasjonsforespørsel og endelig inventar.
  • Versjon endret seg ikke: oppdater native versjonsmetadata og bekreft at den nye source-committen ble løst.
  • Tjeneste feilet: inspiser enheten, runtime-avhengigheter, tillatelser og gjestelogger; legg til en atferdsassertion før rebuild.
BaseimagesDesktop-images