Overview/xpkg — package builder

xpkg - Overview and Status

This is one of four documents describing xpkg, the Rust package builder of the X distribution. It covers what the tool is, its role in the X ecosystem, and its honest status within the xlnux reboot initiative.

Related documents in this folder:

• 02 - Usage
• 03 - Architecture
• 04 - Future integration

What xpkg is

xpkg is the package builder for the X distribution. It reads build recipes (XBUILD or legacy PKGBUILD files), fetches sources, compiles software in an isolated environment, and produces .xp packages ready for installation with xpm. It is the developer companion to xpm.

Think of it as the makepkg + repo-add + namcap equivalent for the X ecosystem, written entirely in Rust.

Project metadata: version 0.1.0, edition 2021, license GPL-3.0-or-later, org xlnux, repository https://github.com/xlnux/xpkg.

Relationship with xpm

xpkg produces .xp packages that xpm installs. Both share the same package format and metadata structures but are independent binaries.

Status inside the xlnux reboot

The xlnux reboot initiative (see ROADMAP.md and DECISIONS.md at the workspace root, outside this repo) reorganised the organisation and set a new direction for the distribution. Its status for the Rust tooling is:

• The workspace roadmap phase "Fase 4 - Tooling Rust (xpm/xpkg)" is POSTPONED. Per the maintainer decision, xpm/xpkg are not worked on during the reboot; the tooling is revisited only when the Rust stack is required again (SAT resolver, .xp repository).
• Packaging of the distribution payload during the reboot is done with PKGBUILD + makepkg (package x-scripts), published to the binary repository x-repo. xpkg is not currently used by the reboot flow.
• Decision ADR-0004 records that xpkg/xpm remain the intended packaging and package-management base of the distribution, under a precondition: the xpm SAT resolver must be wired to install and local .xp file installs must work before depending on xpm for system bootstrap.

In short: xpkg is in a REBOOT PENDING state. The codebase is functional and maintained as the future packager, but it is de-prioritised for now and does not participate in the current reboot delivery flow.

Maturity of the codebase

The repository's own ROADMAP.md reports:

• "Current Status" section: phases 0-3 complete - Cargo workspace scaffolded, CLI with 8 subcommands, TOML configuration parser, XBUILD/PKGBUILD parsers, recipe validation, srcinfo generator, xpkg new, HTTP downloader with retries, SHA-256/512 checksum verification, archive extraction (tar.gz/xz/bz2/zst, zip), Git clone support and source caching, with 72 unit tests passing.
• The phase checklists in the same file mark the later phases (build engine, metadata generation, archive creation, package linting, repository management, verify/info commands) as complete, with two items still open in Phase 9: integration tests with xpm and comparative benchmarks vs makepkg. Phase 10 (post-v1.0 future goals) is entirely open.
• docs/realexample.md records a real end-to-end run: an xfetch package was built into a .xp artifact with xpkg, inspected, linted, added to a local ALPM database and a file:// repository layout under x-repo, and synced by xpm.

Versioning convention

The workspace Cargo.toml currently declares version 0.1.0 for both crates.

Edit this page on GitHub