Trade-off matrix

Compare the operating models, not the checkmarks.

Conary is not the mature choice today. Its near-term bet is that RPM, DEB, and Arch packages can retain their source semantics while one engine owns the transaction on any supported Linux target.

Capability matrix

One row, one defined behavior.

Compared on 2026-07-25

Documentation snapshot · default first-party behavior unless a cell says otherwise

Conary labels describe current maturity. Competitor labels distinguish defaults, version-gated features, adjacent first-party stacks, and different package models. This is not a performance benchmark or an ecosystem-size ranking.

Documentation-based comparison of package-manager operating models, reviewed 2026-07-25.
Defined behaviorConaryaptdnfpacmanNix / NixOS
Dependency selection modelSAT · built-inAPT 3 SAT fallbackSAT · defaultnon-SATevaluated graph
Direct host-distro repository compatibilitynot direct · conversionDEB/APT defaultRPM-md defaultsync repos defaultseparate Nix repos
Reversible native tracking without authority transferpreview-supportedNoNoNoNo
Strict content-addressed package files or outputspackage filesNoNoNoexperimental outputs
Binary package-payload delta downloadsroadmap onlyNo core supportNo in DNF5NoNo standard path
Package-history inverse transactionchangeset-limitedAPT 3.1+built-in historyNogeneration switch
Bootloader-selectable whole-system generationsVM-onlyNorpm-ostree stackNoNixOS default
Alternate root or foreign-architecture toolingbootstrap researchcompanion workflowbuilt-inbuilt-indifferent model
Cross-target package portabilitypreview coreDebian-family modelRPM-family modelArch package modelbroad host support
default, built-in, or preview-supported limited, version-gated, VM-only, or experimental different model, separate stack, roadmap, N/A, or no

Row definitions

What the matrix is actually measuring.

Dependency selection
How the tool chooses a consistent package set from versions, alternatives, providers, and conflicts.
Direct repository compatibility
Consumes the host distro's native repository metadata and binary package format without conversion.
Reversible native tracking
Adds and removes another tool's tracking while the native manager keeps package authority and files.
Strict content addressing
Object identity derives from resulting content, rather than only the build inputs or package filename.
Binary payload deltas
Reconstructs a new package payload from an old payload; repository-index diffs do not count.
Inverse package transaction
A built-in history command attempts to reverse recorded package actions; this is not a filesystem snapshot.
Bootable generations
Retained complete system closures are selectable as boot entries, not merely package-cache downgrades.
Alternate root or architecture
First-party operation targets a root or architecture different from the running host.
Cross-target portability
A source package keeps its version, dependency, payload, configuration, and lifecycle ABI on a host whose native package format differs; equivalent-name mapping alone does not count.

Application semantics

“Transactional” does not mean the same thing.

apt / dpkg

APT resolves and downloads, then dpkg mutates installed paths. Current APT adds history reversal, but interrupted work can still require repair or completion.

dnf / RPM

DNF resolves, verifies, tests, and executes an RPM transaction. History undo and rollback create inverse package actions rather than switching to a retained filesystem image.

pacman / libalpm

pacman prepares and checks a transaction, then commits changes in place. Cached packages support manual recovery, not native transaction undo.

Nix / NixOS

Nix builds side-by-side store paths and atomically repoints profiles. NixOS retains bootable generations, while live activation can still perform stateful service work.

Practical trade-offs

Where Conary fits—and where it does not.

Alongside apt on Ubuntu 26.04 LTS

APT is the established DEB workflow. APT 3 adds a SAT fallback and version-gated history rollback, while dpkg still applies package state in place. Conary can install RPM or Arch inputs on the same host without asking apt or dpkg to own the transaction.

Alongside dnf on Fedora 44

DNF5 uses libsolv and has built-in history reversal. Fedora stopped generating delta RPMs in Fedora 40. Conary adds source-independent DEB and Arch package execution, a reversible adoption bridge, and VM-focused generations.

Alongside pacman on Arch

pacman keeps a direct prepare-and-commit model without native transaction undo or binary payload deltas. Conary can consume RPM and DEB inputs on Arch while retaining their source-native transaction semantics.

Compared with Nix and NixOS

Nix has an established immutable store, atomic profile switching, and a much larger package ecosystem; NixOS adds mature bootable system generations. Strict content-addressed derivation outputs remain experimental rather than the default.

Alongside Flatpak or Snap

Flatpak and Snap distribute applications through runtime or container boundaries. Conary addresses base-system packages, libraries, services, and package authority. They solve different layers and can coexist.

Where Conary is still early

Conary 0.16.1 is an immutable published preview artifact, but it is not current tester authority while the ordinary-package corpus gate remains open. Native CCS packages are few, the cross-distro lifecycle matrix still needs wider installed-host evidence, generation work is VM-only, and the community and operational evidence are small beside established managers.

Method and sources

Claims are tied to named documentation.

Third-party extensions are excluded unless a cell names an add-on or separate stack.

The useful question

Would one package engine across distro boundaries solve a real problem?

Run the bounded preview