
YAP — Yet Another Packager
io.github.M0Rf30由 GitHub 账号 M0Rf30 发布v2.9.0更新于 Nov 7, 2026
Build native Linux packages (.deb/.rpm/.apk/.pkg.tar.zst) from a single PKGBUILD via MCP.
概览
YAP 的配套 MCP 服务器,让助手在隔离容器中从单个 PKGBUILD 构建多种 Linux 原生软件包(.deb、.rpm、.apk、.pkg.tar.zst)。
- 可以做什么
- 从同一份 PKGBUILD 为多个发行版构建软件包,支持按发行版和架构覆盖变量
- 在隔离的 Docker 或 Podman 容器中构建,并可为其他架构交叉编译
- 清理、准备和拉取构建环境,并安装已构建的产物
- 对软件包签名、生成 CycloneDX/SPDX SBOM 附属文件,并查看依赖关系图
- 将构建好的软件包发布到 OpenArtifact 仓库
- 适用场景
- 适合维护 Linux 软件包、希望让助手基于 PKGBUILD 项目驱动构建、签名、SBOM 与发布流程,而不必手动输入命令行参数的场景。
- 运行要求
- 以本地 stdio 进程运行,可使用 yap-mcp 可执行文件或已发布的 OCI 镜像;容器构建需要安装 Docker 或 Podman。发布需要 OpenArtifact 地址与 API 令牌(YAP_OA_URL、YAP_OA_TOKEN 或 YAP_OA_TOKEN_FILE);签名需要密钥材料,可选 YAP_SIGN_PASSPHRASE。YAP_VERBOSE 可开启调试日志。
安装
在 SourceWeft 中
- 打开 控制台中的 YAP — Yet Another Packager,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
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.
来源:README.md,提交 afd7417
工具
0版本历史
9- v2.9.0最新Nov 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
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分