Skip to Content
Building OsCustom software з source repositories

Custom software з source repositories

Рецепти OpenFactory можуть посилатися на Git repository як custom package input на підтримуваних image builders. Це supply-chain-sensitive path: repository, resolved revision, packaging instructions, build dependencies і produced package потребують review.

Support target-specific. Source-package builds відхиляються для деяких builders, включно з поточними Raspberry Pi і Proxmox paths. Підтвердіть availability у normalized recipe і build plan перед обіцянкою, що package буде produced.

Recipe shape

Custom package entries живуть під os.custom_packages:

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

Schema приймає branch name, не immutable commit field. Для controlled release зафіксуйте exact commit, resolved build, і зробіть цей commit частиною retained provenance. Moving branch alone , не reproducible input.

Prepare the repository

Current package path очікує native packaging metadata, відповідну target. Typical examples , Debian debian/ directory або RPM spec. Exact builder behavior і supported target versions можуть змінюватися, тому валідуйте minimal package у deployed environment, а не покладайтеся на static compatibility table.

Для Debian packaging перегляньте щонайменше:

  • debian/control для source/binary identity і dependencies;
  • debian/changelog для package version;
  • debian/rules і інші executable maintainer scripts;
  • install manifests і systemd units; та
  • licensing і bundled third-party material.

Для RPM packaging перегляньте spec sources, build requirements, scriptlets, file list і license metadata.

Never assume repository ownership робить build scripts safe. Package builds виконують untrusted source і packaging logic всередині isolation boundary build infrastructure.

Other package controls

Native packages

Використовуйте os.packages для packages, уже supplied обраним distribution або explicitly configured repository:

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

Package overrides

os.package_overrides може оголошувати add, remove або replace intent:

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

Override , не доказ, що dependency resolution його honored. Verify final package inventory і absence/presence assertions.

Additional repositories

os.extra_repos , advanced input. Не додавайте unsigned HTTP repository, як у старіших прикладах. Approved repository integration потребує HTTPS transport, pinned signing key, signature enforcement, release metadata для package manager і documented ownership і update policy. Якщо ці trust controls не можна представити поточним builder, не використовуйте repository.

Acceptance evidence

Для кожного custom package зберігайте:

  • repository URL і resolved commit;
  • source і declared license review;
  • build environment і dependency snapshot;
  • build logs і resulting package name/version/architecture;
  • package digest і repository-signature evidence, де applicable;
  • final image inventory, що показує installed package;
  • service або executable smoke tests; та
  • removal і upgrade behavior.

Successful source-package stage недостатній. Image build може пізніше fail to consume package, а installed package може бути unusable.

Troubleshooting

  • Packaging metadata rejected: validate native package locally з тим самим distribution release і architecture.
  • Build dependency missing: use dependencies з approved repositories для target; не silently fetch arbitrary binaries у maintainer script.
  • Package absent from the image: compare produced binary package name з normalized install request і final inventory.
  • Version did not change: update native version metadata і confirm new source commit was resolved.
  • Service failed: inspect unit, runtime dependencies, permissions і guest logs; add behavior-level assertion перед rebuild.