Product vision and capability map
Conary starts by making RPM, DEB, and Arch packages source-independent, then connects that package model to building, describing, moving, and recovering Linux systems. The evidence labels show which parts you can rely on today.
A connected system, not a pile of package-manager features.
Install RPM, DEB, and Arch artifacts through one engine while their source format retains version comparison, dependency relations, lifecycle calls, payload metadata, and configuration rules. Target capabilities are explicit inputs; the host distro does not rewrite the package ABI.
Start with the machine already running. Conary can observe native packages, track them reversibly, and keep ownership visible so migration becomes a series of deliberate boundaries instead of one destructive cutover.
Turn the existing recipe, isolated-build, CCS, signing, and static-publication machinery into a coherent workflow that other projects can use—not only an internal bootstrap pipeline.
Describe desired package state, compare it with a host, lock inputs, and connect models to builders and source selection. Over time, that same model can turn a distribution move into an inspectable plan rather than a fresh-install ritual.
Compose package state into content-reusing generations, carry the boot assets needed to run them, and make selection, export, verification, and recovery explicit. Current proof is x86_64 and VM-focused; signed boot authority and broader trust are later work.
Remi already indexes package metadata and serves policy-approved conversions. The longer path connects reliable operator services, agent-facing operations, and trusted federation without making hidden network authority the default.
This is product direction, not an ordered release promise. Post-preview priorities will be selected from external tester evidence.
Cross-distro packages have a documented, inspectable transaction workflow. The packaged tester loop is paused until a release contains the current fixes.
Fedora 44, Ubuntu 26.04 LTS, and Arch can consume RPM, DEB, Arch, and CCS inputs through the same Conary transaction path. Dry-run shows the source ABI and typed target capabilities before automatic target preflight.
sudo conary install ./package.rpm --dry-run sudo conary install ./package.deb --yes sudo conary install ./package.pkg.tar.zst --yesAdoption records packages that remain owned by dnf, apt, or pacman. Unadoption removes Conary tracking without deleting the native package files.
sudo conary system adopt --system --dry-run sudo conary system adopt --system sudo conary list sudo conary search htop sudo conary system unadopt --all --dry-run sudo conary system unadopt --all --yesThe tester lane pins a release, verifies its checksum, records exact commands and exit statuses, and asks for concise public evidence without broad host dumps.
Read the current release statusUseful package machinery whose policy and adapter boundaries still matter.
Conary converts each supported source format into CCS without erasing its native lifecycle ABI, then executes that transaction on any supported target that supplies the declared capabilities. Missing capability models are engineering gaps, not string-matching review policy.
sudo conary install ./package.rpm --dry-run sudo conary install ./package.deb --dry-run sudo conary install ./package.pkg.tar.zst --dry-runConary-owned files are stored by content hash, while resolvo handles conflicts, virtual provides, and typed dependencies. CAS garbage collection remains tied to database reference counts.
conary query deptree nginx conary query depends nginx conary query rdepends openssl conary system verifyCCS uses CBOR manifests, Merkle verification, Ed25519 signatures, and content-defined chunking. Signing requires an explicit private key path.
conary ccs build . conary ccs sign --key private.pem package.ccs conary ccs verify package.ccs conary ccs inspect package.ccsPackage changesets track database and file state without implying a bootable generation for every install. Configuration paths can be inspected, backed up, and restored where current package metadata supports the operation.
Advanced state selection and recovery paths that are separate from the first package loop.
The generation path builds EROFS artifacts and can use compatible composefs and fs-verity support. Rollback selects an earlier generation; it is not the undo mechanism for every package transaction.
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 --yesUse a VM. The basic package loop does not require composefs, fs-verity, or boot-stack changes.
Desired package state can be described and compared with the host. Live apply remains 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 checkThe source tree includes three-way merge machinery for /etc, artifact
validation, database-backed rebuild paths, and older-generation scanning. Treat
all of it as advanced VM evidence, not first-run onboarding.
Real interfaces in the source tree without a reliable stranger-operated onboarding contract.
The staged bootstrap pipeline covers cross-tools through image creation, with experimental x86_64, aarch64, and riscv64 source-build targets. Published tester packages and current generation evidence remain x86_64.
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.
conary federation status conary federation peersThe public --isolated cook path adds Linux namespace isolation. It is
not a complete reproducibility or containment guarantee. Advanced 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.tomlValuable directions that are not capabilities to plan production work around yet.
Chunk reuse and generation-delta work remain broader artifact-roadmap items. The current release makes no public delta-size or bandwidth-reduction claim.
The source-independent package contract is not tied to three distro names, but release claims still need installed-binary matrix proof on additional mainstream targets and architectures before they join the supported list.
No SBOM or provenance sidecars are published or planned for this limited preview. Broader scriptlet authority, non-x86 boot artifacts, and wider recovery proof must remain separate evidence-bearing work.
The first step is ready
The install runbook pins the package, checksum, command order, and feedback contract so the vision begins with real evidence.