Use when packaging a project that provides official pre-built static binaries, when building from source is impractical, or when you need a bootstrap compiler
Install with Tessl CLI
npx tessl i github:projectbluefin/dakota --skill packaging-pre-built-binaries75
Quality
61%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Optimize this skill with Tessl
npx tessl skill review --optimize ./.opencode/skills/packaging-pre-built-binaries/SKILL.mdrust-stage1)Every pre-built binary element MUST have these:
| Setting | Why |
|---|---|
variables: strip-binaries: "" | Pre-built binaries aren't ELF from our toolchain. Without this, build fails during strip phase. |
build-depends: freedesktop-sdk.bst:public-stacks/runtime-minimal.bst | Provides install, sed, and other basic tools needed by install-commands. |
Use when the project only targets one architecture or you're writing the per-arch element file.
kind: manual
build-depends:
- freedesktop-sdk.bst:public-stacks/runtime-minimal.bst
sources:
- kind: tar # or 'remote' for single files
url: github_files:org/repo/releases/download/vX.Y.Z/package_X.Y.Z_arch.tgz
ref: <sha256>
variables:
strip-binaries: ""
config:
install-commands:
- |
install -Dm755 -t "%{install-root}%{bindir}" binary1 binary2
- |
# Install systemd service (if applicable)
install -Dm644 -t "%{install-root}%{indep-libdir}/systemd/system" path/to/service.service
- |
# Install systemd preset to enable the service
install -Dm644 /dev/stdin "%{install-root}%{indep-libdir}/systemd/system-preset/80-name.preset" <<'PRESET'
enable service-name.service
PRESET
- |
%{install-extra}Binary tarball URLs almost always differ per architecture. BuildStream does NOT support variable substitution in sources: URLs or (?): conditionals on sources: blocks. The only option is a multi-arch dispatcher.
Create these files:
Per-arch elements -- each with its own source URL and SHA256:
elements/bluefin/package-x86_64.bstelements/bluefin/package-aarch64.bstStack dispatcher (elements/bluefin/package.bst):
kind: stack
(?):
- arch == "x86_64":
depends:
- bluefin/package-x86_64.bst
- arch == "aarch64":
depends:
- bluefin/package-aarch64.bstThe dispatcher is what other elements depend on. It selects the correct arch-specific element at build time.
Upstream service files often need patching for GNOME OS:
/usr/sbin/ -> /usr/bin/ -- GNOME OS uses merged-usr; everything lives in /usr/binEnvironmentFile=/etc/default/... -- GNOME OS doesn't use /etc/default/systemctl enable -- presets are declarative and sandbox-safePatching pattern:
sed -e 's|/usr/sbin/|/usr/bin/|g' \
-e '/^EnvironmentFile=/d' \
upstream.service > patched.service
install -Dm644 -t "%{install-root}%{indep-libdir}/systemd/system" patched.servicePreset pattern:
install -Dm644 /dev/stdin "%{install-root}%{indep-libdir}/systemd/system-preset/80-name.preset" <<'PRESET'
enable service-name.service
PRESETgithub_files: alias -- e.g., github_files:org/repo/releases/download/vX.Y.Z/file.tgzinclude/aliases.yml under the # file aliases section.sha256 files alongside releases: curl -sL <url>.sha256Tailscale v1.94.2 is packaged as pre-built static binaries for x86_64 and aarch64.
Files:
elements/bluefin/tailscale-x86_64.bst -- amd64 tarballelements/bluefin/tailscale-aarch64.bst -- arm64 tarballelements/bluefin/tailscale.bst -- stack dispatcherKey decisions:
github_files: alias (Tailscale publishes to GitHub Releases)/usr/sbin/ -> /usr/bin/, removed EnvironmentFile=80-tailscale.preset to enable tailscaled.servicestrip-binaries: "" (pre-built Go static binaries)Per-arch element (tailscale-x86_64.bst):
kind: manual
build-depends:
- freedesktop-sdk.bst:public-stacks/runtime-minimal.bst
sources:
- kind: tar
url: github_files:tailscale/tailscale/releases/download/v1.94.2/tailscale_1.94.2_amd64.tgz
ref: c6f99a5d774c7783b56902188d69e9756fc3dddfb08ac6be4cb2585f3fecdc32
variables:
strip-binaries: ""
config:
install-commands:
- |
install -Dm755 -t "%{install-root}%{bindir}" tailscale tailscaled
- |
sed -e 's|/usr/sbin/tailscaled|/usr/bin/tailscaled|g' \
-e '/^EnvironmentFile=/d' \
systemd/tailscaled.service > tailscaled.service.patched
install -Dm644 -t "%{install-root}%{indep-libdir}/systemd/system" tailscaled.service.patched
mv "%{install-root}%{indep-libdir}/systemd/system/tailscaled.service.patched" \
"%{install-root}%{indep-libdir}/systemd/system/tailscaled.service"
- |
install -Dm644 /dev/stdin "%{install-root}%{indep-libdir}/systemd/system-preset/80-tailscale.preset" <<'PRESET'
enable tailscaled.service
PRESET
- |
%{install-extra}Zig SDK: When packaging Zig projects, the Zig compiler is downloaded as a pre-built tarball and used as a build dependency. It follows the same pattern -- kind: manual, strip-binaries: "", tar source with SHA256 ref. It's a bootstrap compiler, not a runtime package. See the packaging-zig-projects skill for the full workflow.
Pre-built binaries like Tailscale are NOT tracked by any automated dependency update mechanism (Renovate, bst source track, etc.). Updates are entirely manual:
refbst build elements/bluefin/<package>.bst)This is a known gap. When working on pre-built binary elements, always check whether the pinned version is current.
| Mistake | Symptom | Fix |
|---|---|---|
Forget strip-binaries: "" | Build fails during strip phase | Add variables: strip-binaries: "" |
Use /usr/sbin in paths | Binary not found at runtime | Always use %{bindir} (/usr/bin) |
Use EnvironmentFile=/etc/default/ | Service fails to start | Remove directive, inline defaults |
| Use variables in source URLs | YAML parse error or wrong URL | Use multi-arch dispatcher pattern |
Forget %{install-extra} | Breaks extensibility convention | Always end install-commands with it |
Wrong install argument order | Files installed to wrong location | Use -t DIR FILE form for clarity |
| Forget preset file | Service not enabled on boot | Add 80-<name>.preset with enable |
| Tarball has no wrapping directory | Could not find base directory matching pattern: * | Add base-dir: "" to the tar source (common with Go single-binary releases like fzf) |
updating-upstream-refs — For the version bump workflow when updating pre-built binary versions. Covers tracking refs, testing builds, and validating changes.d624581
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.