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.