Capability map

What works, what is early, and what is not there yet.

Every capability below carries the label the roadmap gives it, not the one marketing would prefer. Proven means exercised by the integration harness on the current tree inside Fedora 44, Ubuntu 26.04 LTS, and Arch Linux containers.

proven · three hosts

The cross-distro package loop

Exercised by the integration harness inside containers for all three supported distributions, against a harness-served fixture repository. The release matrix records the artifact proof and its limits for v0.17.2. Still pre-alpha: proven means it ran, not that it is safe on a machine you rely on.

source-format exact

Cross-distro package install

Fedora 44, Ubuntu 26.04 LTS, and Arch consume RPM, DEB, Arch, and CCS inputs through the same transaction path. Each package keeps its source lifecycle, dependency, version, payload, and configuration semantics. Dry-run shows the source ABI and the typed target capabilities it needs; preflight rejects an unsatisfied capability before anything is mutated, and there is no bypass flag.

sudo conary install ./package.rpm --dry-run sudo conary install ./package.deb --yes sudo conary install ./package.pkg.tar.zst --yes sudo conary install htop --from ubuntu-26.04 --dry-run
reversible

Adoption and unadoption

Adoption records packages that stay owned by dnf, apt, or pacman so Conary can see them without taking them over. Unadoption removes the tracking and deletes nothing. It is the migration bridge for a machine you already have, not the product's main path.

sudo conary system adopt --system --dry-run sudo conary system adopt --system sudo conary system adopt --status sudo conary system unadopt --all --dry-run sudo conary system unadopt --all --yes
signed release

Verified installation and self-update

Each release ships checksums, a detached signature for the CCS artifact, and an Ed25519-signed bootstrap manifest that binds every supported host to one exact package. The bootstrap script verifies the manifest before it reads a single selection field, and the installed client can check for and apply its own updates.

sudo conary self-update --check sudo conary self-update
Open the install guide
available · limited

Package machinery Conary owns

Working package internals whose policy and adapter boundaries still matter.

core machinery

Content-addressed storage and SAT resolution

Conary-owned files are stored by content hash so identical content is kept once. A SAT solver (resolvo) handles conflicts, virtual provides, and typed dependencies. Garbage collection of the store follows database reference counts.

conary query deptree nginx conary query depends nginx conary query rdepends openssl conary query whatprovides 'soname(libssl.so.3)' sudo conary system verify
native format

Build, sign, verify, and inspect CCS

CCS is Conary's native package format: a CBOR manifest, SHA-256 content verification, Ed25519 signatures, and FastCDC content-defined chunking for large files. Signing requires an explicit private key.

conary ccs build . conary ccs sign --key private.pem package.ccs conary ccs verify package.ccs conary ccs inspect package.ccs
changeset-backed

Changesets and configuration handling

Every install, update, and remove is a durable changeset with an explicit pending, applied, failed, or rolled-back outcome. A changeset records database and file state; it does not imply a bootable generation for every install, and it does not promise universal filesystem rollback. Configuration files follow their source format's exact rules.

shared service

Remi, the package service

remi.conary.io authenticates the Fedora, Ubuntu, and Arch repositories, converts their packages to CCS on demand, and serves them with the source-format lifecycle contract intact. A package can fail conversion even when upstream serves it fine; that is feedback, not a verdict on the package. Its first complete signed public universe is still an open launch gate.

sudo conary repo list sudo conary repo sync remi sudo conary search htop
VM evidence

System generations

Whole-system state selection and recovery. Separate from the package loop, and proven only in virtual machines.

Linux 6.2+ · x86_64

Build, select, and export EROFS generations

A generation is an immutable EROFS image of the system, mounted through composefs with fs-verity where the kernel supports it. Rollback selects an earlier generation for the next boot. Generations can be exported as raw, qcow2, or x86_64 UEFI ISO images for validation.

sudo conary system generation build --summary "Post-update" --yes sudo conary system generation list sudo conary system generation switch 2 --yes sudo conary system generation rollback --yes sudo conary system generation gc --keep 3 --yes sudo conary system generation export --path /conary/generations/1 --format qcow2 --output gen1.qcow2

Use a VM. The package loop above does not need composefs, fs-verity, or any boot-stack change.

explicit apply

Declarative system model

Desired package state can be described and diffed against the host. Live apply stays a VM-only path until it has the same recovery evidence as package mutation.

conary model diff sudo conary model apply --dry-run sudo conary model apply --yes conary model check
recovery surface

Configuration merge and recovery

The tree includes three-way merge for /etc, generation artifact validation, and database-backed rebuild paths. Treat all of it as advanced VM evidence, not first-run onboarding.

experimental

Infrastructure and build surfaces

Real interfaces in the source tree without a reliable onboarding contract for strangers.

source-build research

Bootstrap and architecture targets

A staged bootstrap pipeline runs from cross-tools through image creation, with experimental x86_64, aarch64, and riscv64 source-build targets. Published packages and all generation evidence remain x86_64.

not onboarding

conaryd and CAS federation

conaryd is a local daemon with Unix-socket REST and SSE scaffolding. Federation is outside the reliable limited-preview path: peer discovery, routing, and chunk-sharing surfaces exist, but coordinator and serving paths are not yet wired into one supported operating model. Neither is a fleet service.

conary federation status conary federation peers
incomplete integration

Recipes and derivations

Conary can build a package from a recipe. The --isolated cook path adds Linux namespace isolation. It is not a complete reproducibility or containment guarantee. Derivation, lock, and update flows still have incomplete persisted inputs and integration edges.

conary cook recipe.toml conary cook --isolated recipe.toml conary cook --fetch-only recipe.toml
not built

What is not there yet

Stated so nobody plans around it.

not implemented

Native transaction-history import

Conary does not import dnf, apt, or pacman transaction history. Adoption records current package ownership, not the past.

roadmap

Generation and payload deltas

Chunk reuse and generation-delta work remain roadmap items. No release makes a delta-size or bandwidth-reduction claim.

proof expansion

More distributions and architectures

The package contract is not tied to three distro names, but a host joins the supported list only after installed-package proof on it. Non-x86_64 generation boot assets are still reserved.

not published

SBOM and provenance sidecars

Releases carry checksums, a CCS signature, and a signed bootstrap manifest. They do not carry SBOM or provenance sidecars.

direction

Where it is going

Product direction, not an ordered release promise. Priorities after the preview will come from tester evidence.

direction

Third-party package building and publishing

Turn the existing recipe, isolated-build, CCS, signing, and static-publication machinery into a workflow other projects can use, not only an internal bootstrap pipeline.

direction

Replatforming as a plan, not a ritual

Connect the declarative model to builders and source selection so a distribution move becomes an inspectable plan rather than a fresh install.

direction

Agent-facing operations without hidden authority

A typed, versioned agent contract already exists in the tree and MCP adapts it. The longer path connects operator services and automation without making network authority the default.

Start with the install path

Install the pre-alpha on a disposable host.

The install guide verifies the signed release before anything is applied and shows where the tester loop stands.

Open the install guide