Project context
An old packaging idea, rebuilt from scratch.
Conary takes inspiration from a visionary mid-2000s design, then starts again in Rust with a deliberately narrower public preview and a modern generation model.
Independent project
This is a ground-up reimplementation in Rust—not a fork, port, resurrection, or continuation of the original rPath Conary codebase. It is not affiliated with, endorsed by, or maintained by rPath, SAS, or the original Conary developers.
Origins
The ideas outlived the first implementation.
The name is carried forward as a tribute to the engineering that got there first.
- mid-2000s
rPath builds the original Conary
The original Conary package manager, developed by the rPath team, pioneered content-addressable package storage, repository-level binary diffs, a SAT-based resolver, and rollback of system state.
- 2011
The implementation goes dormant
The Python 2 implementation was tied to rPath Linux and Foresight Linux. After SAS acquired rPath, the project went dormant while its package-management ideas remained relevant.
- now
Conary starts again in Rust
The current project treats the filesystem as a content store, gives mutations explicit transaction and recovery boundaries, and resolves dependencies before applying changes—without reusing the original codebase.
The problem
Linux package state is fragmented by distribution.
Every distribution maintains its own package format, repositories, tools, and transaction model. Switching hosts means changing commands and expectations, while package availability and recovery behavior vary.
Conary does not ask upstream maintainers to change their packages. Remi converts RPM, DEB, and Arch inputs into source-independent CCS transactions that retain the source package ABI and run against typed target capabilities.
The first cross-distro tester loop installs a foreign-format artifact, inspects it, plans an update, and removes it. Adoption remains a separate migration path for packages already owned by the host package manager.
Architecture
Package state, content, and generation artifacts stay distinct.
- CAS layer
- Files are stored by hash rather than only by package, allowing identical content to be deduplicated.
- Resolver
- resolvo provides SAT-based dependency resolution across conflicts, virtual provides, and typed dependencies.
- Format parsers
- RPM, DEB, and Arch parsers preserve exact lifecycle, dependency, version, payload, and configuration semantics in a shared source-independent model.
- Package changesets
- Package operations commit database and file state through explicit changesets rather than implying a bootable generation for every install.
- Generation artifacts
- The advanced path builds EROFS images and can integrate composefs and fs-verity on compatible hosts.
- System model
- Desired package state can be declared and inspected for drift; live application remains a VM-only follow-up.
- Delta work
- CAS chunking and generation-delta work remain broader roadmap items, not a size-reduction promise for the first tester loop.
- Bootstrap
- A staged pipeline builds from cross-tools through a complete system image, with experimental architecture targets beyond the packaged x86_64 tester lane.
Implementation
The current stack
- Language
- Rust, Edition 2024 · 8-member Cargo workspace
- Filesystem
- EROFS · optional composefs and fs-verity integration for generations
- Database
- SQLite · current schema epoch · explicit rebuild boundary · DB-first runtime state
- Hashing
- SHA-256 · XXH128
- Compression
- Zstd · Gzip · XZ
- Server
- Axum · Tantivy full-text search
- Resolver
- resolvo SAT solver
Contribute
Help turn preview evidence into a trustworthy package manager.
The repository includes unit, integration, harness, formatting, lint, documentation-truth, and release workflows. Open issues and the contributing guide are the current entry points.