Overview/xpm — package manager
xpm — Overview and Status
This document describes what xpm is, where it sits inside the X ecosystem, and its honest
current status within the reboot initiative. It is based on the repository contents as they are
today (README.md, ROADMAP.md, source code, tests, docs/), not on an intended future state.
What xpm is
xpm is a modern, high-performance package manager written in pure Rust for the X distribution.
It is designed as a native Rust replacement for pacman and libalpm:
- Native
.xppackage format (X Package, atar.zstarchive) with.PKGINFO,.BUILDINFO, and.MTREEmetadata. - Compatibility with Arch Linux
.pkg.tar.zstpackages and ALPM-style repository databases (.db/.files). - SAT-based dependency resolution powered by the
resolvocrate. - TOML configuration file at
/etc/xpm.conf. - OpenPGP detached signature verification with a configurable
sig_level(required/optional/never). - Repository management with predefined repositories plus user-added repositories under
/etc/xpm.d/.
The project belongs to the equislinux organization. Packages are built by the companion builder
tool xpkg (repo equislinux/xpkg); xpm consumes what xpkg produces.
Position in the x-lnux workspace
The workspace /home/x0z/Documents/repos/x-lnux is not a single repository; each folder is an
independent GitHub repo with its own origin. The relevant folders are:
| Folder | Repo | Role |
|---|---|---|
x | equislinux/x | The distro (archiso build of image/ISO and provisioning) |
scripts | equislinux/scripts | System kickstart / provisioning scripts |
xpkg | equislinux/xpkg | Rust packaging tool (builder) |
xpm | equislinux/xpm | Rust package manager (this repo) |
x-repo | equislinux/x-repo | Package repository and portal |
This repo follows the shared conventions of the workspace: work for the reboot initiative lives
on the x/reboot branch of each repo, commits stay local (no push), and messages carry no emojis
or external-tool references.
Current status (honest)
The repository exists, compiles, and carries a substantial test suite (unit tests across both
crates plus integration tests under tests/). Within the reboot initiative, however, xpm is
de-prioritised:
- The workspace-level ROADMAP marks Phase 4 "Tooling Rust (xpm/xpkg)" as postponed
(
POSPUESTA). By maintainer decision, xpm/xpkg is out of the current scope. - Today the distro payload is packaged as the
x-scriptspackage using a PKGBUILD + makepkg flow and is published tox-repothrough the pacman-compatible repository. Consumption on installed systems goes through pacman, not through xpm. xpmis therefore not yet the active path in the reboot flow. It is a functioning tooling codebase with its own internal roadmap, waiting to be revisited when the native.xprepository is actually required (the SAT resolver is already wired intoinstall).- Independently of the reboot scope, the
feat/generations-alignmentbranch landed a self-contained slice: a transaction journal plusxpm history, transaction hooks (pre/post-transaction.dwith theXPM_*contract), a machine-readablexpm queryand realxpm files/xpm infobacked byreason/origin/filesmetadata in the local database, plusxpm searchandquery --orphansover the recorded dependency graph. The SAT resolver is now wired intoinstall; rollback remains pending.
The repository still publishes its own binaries as .xp packages in the xpm-native tree (see the
README for the key bootstrap and signature checklist), which is separate from the pacman path
used in production today. The two layouts must not be confused: the xpm-native endpoint is
https://equislinux.github.io/x-repo/x/$arch, not the pacman endpoint under /repo/x86_64.
Internal roadmap and milestones
xpm keeps its own ROADMAP.md inside this repo with phases 0-10. Progress highlights:
- Phases 0-1 complete: scaffolding, CLI with 8 subcommands plus
repo/usage, TOML config. - Phase 2 (libalpm FFI bridge) skipped by design — the project went straight to native Rust to avoid C dependencies.
- Phase 3 complete: SAT resolver using
resolvo, ALPMvercmpversion comparison, dependency parsing, conflict handling, integration tests. - Phase 4 complete:
.xp/.pkg.tar.zstreaders, metadata parsers, archive extraction, and post-install integrity validation. - Phase 5 largely complete: ALPM
.db/.filesparsing, local database under/var/lib/xpm/local/, remote sync with HTTP downloads, GitHub Pages backend, URL variable substitution. - Phase 10 security execution track: detached
.db.sigand package.sigverification plus keyring loading are implemented. - Generation alignment (branch
feat/generations-alignment): transaction journal under/var/lib/xpm/journal/,xpm history [--json],pre/post-transaction.dhooks,querywith--format tsvand install-reason filters, and local-database metadata forfiles/infoare implemented.
The versioning convention in the repo roadmap is:
| Version | Milestone |
|---|---|
v0.1.0 | Phases 0-1 complete (functional CLI with configuration) |
v0.2.0 | Phase 2 skipped (no libalpm dependency) |
v0.5.0 | Phases 3-5 complete (native engine operational) |
v0.8.0 | Phases 6-7 complete (security + transactions) |
v1.0.0 | Phase 8 complete (benchmarked, tested, production-ready) |
The workspace Cargo.toml currently reports version 0.1.0.
About the command state
All read subcommands are wired to engine logic. From crates/xpm/src/main.rs:
sync,install,remove,upgrade,repo,history,query(including--orphans, which walks the dependency edges recorded at install time),search,infoandfilesdispatch to real engine logic.- Still missing:
rollback --last,diff <generation>and.pacnew/.pacsavehandling.
See Usage for the full reference and Architecture for the implementation details.