
YAP — Yet Another Packager
io.github.M0Rf30Published by GitHub account M0Rf30v2.9.0Updated Nov 7, 2026
Build native Linux packages (.deb/.rpm/.apk/.pkg.tar.zst) from a single PKGBUILD via MCP.
Overview
YAP's companion MCP server that lets an assistant build native Linux packages (.deb, .rpm, .apk, .pkg.tar.zst) from a single PKGBUILD in isolated containers.
- What you can do
- Build packages for multiple distributions from one PKGBUILD, with distro and architecture overrides
- Run builds in isolated Docker or Podman containers, including cross-compilation for other architectures
- Clean, prepare and pull build environments, and install built artifacts
- Sign packages, generate CycloneDX/SPDX SBOM sidecars, and inspect dependency graphs
- Publish built packages to an OpenArtifact repository
- When to use it
- Useful when you maintain Linux packages and want an assistant to drive the build, signing, SBOM and publishing steps from a PKGBUILD-based project instead of typing CLI commands.
- Requirements
- Runs as a local stdio process, either the yap-mcp binary or the published OCI image; Docker or Podman must be installed for container builds. Publishing needs an OpenArtifact URL and API token (YAP_OA_URL, YAP_OA_TOKEN or YAP_OA_TOKEN_FILE); signing needs key material and optionally YAP_SIGN_PASSPHRASE. YAP_VERBOSE enables debug logging.
Installation
In SourceWeft
- Open YAP — Yet Another Packager in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
YAP — Yet Another Packager
[yap-logo][report card] [View examples] [License: GPL v3] [GitHub release]
YAP builds native packages for multiple GNU/Linux distributions from a single PKGBUILD specification. Write your package once; get .deb, .rpm, .apk, and .pkg.tar.zst out. All builds run in isolated OCI containers (Docker or Podman).
Features
- Multi-format output: DEB (Debian/Ubuntu), RPM (Fedora/RHEL/Rocky/openSUSE), APK (Alpine), TAR.ZST (Arch)
- Container isolation: reproducible builds, no host contamination, Docker and Podman supported
- PKGBUILD-based: familiar Arch Linux syntax extended with distribution and architecture overrides
- Cross-compilation: build for a different architecture than your host
- Dependency-aware builds: sequential by default; opt-in parallel topo-sort via
--parallel - Package signing: APK RSA + DEB/RPM/Pacman GPG (no
gpgbinary required) - SBOM generation: CycloneDX 1.5 and SPDX 2.3 sidecars
- Publishing:
yap publishuploads DEB/RPM (and APK/Pacman as raw files) to an OpenArtifact repository - Per-format compression:
zstd/gzip/xzfor DEB and RPM - Changelog support:
changelogPKGBUILD field renders to native format per distro - Pacman scriptlets: full 6-hook lifecycle (pre/post install/upgrade/remove)
- Structured logging: slog-based, tree rendering for long lines, zero external UI deps
Installation
One-liner (Linux/macOS, amd64/arm64):
Pin a version or install only one tool:
Manual download:
Build from source
Requires Docker or Podman:
Quick start
1. Project structure
Create yap.json:
2. PKGBUILD
Create my-package/PKGBUILD:
3. Build
4. Output
Project configuration (yap.json)
Build ordering between packages comes from the install flag and each
PKGBUILD's depends/makedepends — there is no yap.json-level depends
field. See yap.schema.json for the complete spec.
Editor validation (JSON Schema)
A JSON Schema for yap.json ships at the repo root: yap.schema.json.
It documents every supported field (compression, signing, repos, SBOM,
cross-compilation, etc.). Reference it from your yap.json for autocomplete and
inline validation in editors that support JSON Schema:
The schema is published on SchemaStore,
so editors (VS Code, JetBrains, Neovim, …) validate any yap.json by filename
automatically — no $schema line required.
PKGBUILD extensions
Distribution-specific variables
Use __ (double underscore) to override any variable per distribution. Priority (highest wins):
Architecture-specific variables
Supported architectures: x86_64, i686, aarch64, armv7h, armv6h, armv5, ppc64, ppc64le, s390x, mips, mipsle, riscv64, pentium4, any.
Checksum types
Supported (strongest to fastest): b2sums, sha512sums, sha384sums, sha256sums, sha224sums, cksums.
Changelog
- DEB:
usr/share/doc/<pkgname>/changelog.Debian.gz(Lintian-compliant) - RPM: native
%changelogentries embedded in package metadata - Pacman:
.CHANGELOGin the archive - APK: ignored (no Alpine convention)
Pacman scriptlets
Emitted to <pkgname>.install only when at least one hook is defined. pre/post_upgrade fall back to pre/post_install when absent.
Package manager-specific fields
Supported distributions
Model Context Protocol (MCP)
YAP ships a companion yap-mcp binary that exposes the same build pipeline
over the Model Context Protocol, so any
MCP-compatible LLM client (Claude Desktop, opencode, Cursor, Zed, Continue,
Goose, …) can drive yap directly.
Quickstart (release binary):
Or pull the standalone OCI image (also listed on the
MCP registry as io.github.M0Rf30/yap):
Claude Code plugin (server + skill in one)
Smithery
The full tool surface, per-client config snippets, security model, and
troubleshooting are in MCP.md. The shipped skill card at
skills/yap/SKILL.md follows the Anthropic Agent
Skills layout and gives agents a workflow cheatsheet for free. Distribution
channels and release steps are documented in PUBLISHING.md.
CLI reference
Commands
Build flags
Shell completion
Package signing
Signing uses github.com/ProtonMail/go-crypto/openpgp — no gpg binary required.
Key resolution (highest to lowest)
--sign-key <path>CLI flag- Format env:
YAP_APK_KEY,YAP_DEB_KEY,YAP_RPM_KEY,YAP_PACMAN_KEY - Global env:
YAP_SIGN_KEY yap.jsonfieldsigning.keyPath~/.config/yap/keys/<format>.{rsa,gpg}then~/.config/yap/keys/default.{rsa,gpg}
Passphrase resolution mirrors key resolution with _PASSPHRASE suffix.
yap.json signing config
Verifying signed packages
Publishing to OpenArtifact
yap publish uploads built packages to a hosted
OpenArtifact repository, which
serves the apt/dnf indexes (Release, Packages, repomd.xml) itself.
Settings resolve in this order (later wins): the publish object of
yap.json, the YAP_OA_* environment, command-line flags.
Other flags: --config <yap.json|dir> (default ./yap.json), --retries <n>
(attempts per request, default 3), --timeout <duration> (per request, default
30m), --insecure-http, --dry-run.
Behaviour:
- Token: an OpenArtifact API token with write permission on the target
repositories (a
deploytoken,oa_dep_…, is enough). It is sent asAuthorization: Bearer …, is never accepted fromyap.jsonor a flag value (so it stays out of the process list), and is redacted from logs and errors. The token is only sent overhttps, orhttpto a loopback host unless you pass--insecure-http. - Arguments: package files and/or directories. Without arguments the
outputdirectory ofyap.jsonis published. Packages found while scanning a directory whose format has no repository configured are skipped with a warning; an explicitly named file in that situation is an error. - Verification: the SHA-256 returned by the server (or
X-Checksum-Sha256for raw files) must equal the local file's, otherwise the publish fails. - Retries: connection errors and HTTP 408/429/5xx are retried with exponential backoff and jitter; other 4xx answers (bad token, wrong repository, invalid package) fail immediately.
- Idempotent: DEB/RPM packages are immutable on the server, which answers
409. yap then looks the SHA-256 up in the repository listing: identical bytes count as success ("unchanged"), different bytes under the same name and version fail. Raw files are skipped whenX-Checksum-Sha256already matches and replaced otherwise (unless the repository enforces immutable releases, which fails the publish). - Signatures: OpenArtifact signs repository indexes; yap's per-package
.ascfiles are not uploaded for DEB/RPM. For APK/Pacman raw repositories the.sig/.ascsidecars are uploaded next to the package.
Exit status is non-zero if any package failed; the remaining packages are still attempted.
SBOM generation
Output alongside each artifact:
Captured: name, version, license, runtime/build deps, source URLs and checksums, file hashes, DESCRIBES/DEPENDS_ON relationships.
Advanced usage
Cross-compilation
YAP installs the required cross-compilation toolchains and configures the build environment automatically.
Multi-package projects
Packages with "install": true are installed immediately after building so subsequent packages can use them as build-time dependencies.
Build environment preparation
CI/CD integration
GitHub Actions
GitLab CI
Examples
The examples directory contains complete, ready-to-build projects:
PKGBUILD examples
Simple C application
Python application
Web service with systemd
Development
Make targets
Testing
Tests must run sequentially (-p 1):
Internationalization
Supported languages: English (en), Italian (it).
Language is auto-detected from LANG/LC_ALL/LC_MESSAGES/LANGUAGE. Override with --language / -l:
To add a language: copy pkg/i18n/locales/en.yaml to pkg/i18n/locales/{code}.yaml, translate, add the code to SupportedLanguages in pkg/i18n/i18n.go, submit a PR.
Troubleshooting
Container runtime
Build failures
Permission issues
Performance
Contributing
- Fork the repository
- Create a feature branch:
git checkout -b feature/my-feature - Make changes and add tests
- Run
make fmt lint test - Commit and open a pull request
See CODE_OF_CONDUCT.md for community guidelines.
License
GNU General Public License v3.0. See LICENSE.md.
Credits
- Zachary Huff for contributions to Pacur, the project that inspired YAP
- The Arch Linux community for the PKGBUILD format
- All contributors
Built with Go, Cobra, Docker / Podman.
Source: README.md at commit afd7417
Tools
0Version history
9- v2.9.0LatestNov 7, 2026
- v2.8.0Oct 23, 2026
- v2.7.6Oct 21, 2026
- v2.7.2Oct 13, 2026
- v2.7.1Oct 5, 2026
- v2.7.0Oct 5, 2026
- v2.6.3Sep 24, 2026
- v2.6.2Sep 16, 2026
- v2.6.1Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts