X Linux
Documentation menu

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 .xp package format (X Package, a tar.zst archive) with .PKGINFO, .BUILDINFO, and .MTREE metadata.
  • Compatibility with Arch Linux .pkg.tar.zst packages and ALPM-style repository databases (.db / .files).
  • SAT-based dependency resolution powered by the resolvo crate.
  • 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:

FolderRepoRole
xequislinux/xThe distro (archiso build of image/ISO and provisioning)
scriptsequislinux/scriptsSystem kickstart / provisioning scripts
xpkgequislinux/xpkgRust packaging tool (builder)
xpmequislinux/xpmRust package manager (this repo)
x-repoequislinux/x-repoPackage 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-scripts package using a PKGBUILD + makepkg flow and is published to x-repo through the pacman-compatible repository. Consumption on installed systems goes through pacman, not through xpm.
  • xpm is 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 .xp repository is actually required (the SAT resolver is already wired into install).
  • Independently of the reboot scope, the feat/generations-alignment branch landed a self-contained slice: a transaction journal plus xpm history, transaction hooks (pre/post-transaction.d with the XPM_* contract), a machine-readable xpm query and real xpm files/xpm info backed by reason/origin/files metadata in the local database, plus xpm search and query --orphans over the recorded dependency graph. The SAT resolver is now wired into install; 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, ALPM vercmp version comparison, dependency parsing, conflict handling, integration tests.
  • Phase 4 complete: .xp / .pkg.tar.zst readers, metadata parsers, archive extraction, and post-install integrity validation.
  • Phase 5 largely complete: ALPM .db / .files parsing, 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.sig and package .sig verification plus keyring loading are implemented.
  • Generation alignment (branch feat/generations-alignment): transaction journal under /var/lib/xpm/journal/, xpm history [--json], pre/post-transaction.d hooks, query with --format tsv and install-reason filters, and local-database metadata for files/info are implemented.

The versioning convention in the repo roadmap is:

VersionMilestone
v0.1.0Phases 0-1 complete (functional CLI with configuration)
v0.2.0Phase 2 skipped (no libalpm dependency)
v0.5.0Phases 3-5 complete (native engine operational)
v0.8.0Phases 6-7 complete (security + transactions)
v1.0.0Phase 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, info and files dispatch to real engine logic.
  • Still missing: rollback --last, diff <generation> and .pacnew/.pacsave handling.

See Usage for the full reference and Architecture for the implementation details.

Edit this page on GitHub