Package management is where a system either respects your time or quietly steals it. Two decisions usually get made together and are worth separating: what the package manager does when a transaction fails, and when you pay for change. 0dyssey is being built on xbps and a rolling Void base. Both halves of that reasoning generalise past either choice.
The first test: what happens halfway through
The interesting moment in a package manager is not the successful install. It is the one that dies in the middle: a dropped connection, a full disk, a Ctrl-C at the wrong second, a power cut during an upgrade.
A package manager passes that test when the interruption leaves you exactly where you started, with a database that still describes the system you actually have. It fails when it leaves you somewhere in between, with half a transaction applied and a database that now describes a machine that does not exist. The recovery procedure for the second case is folklore, and folklore does not scale to a system other people are running.
xbps applies installs and removals as transactions: they complete or they roll back. That single property is why it is in the stack. It is also quick, because the package format and the dependency resolver were designed together rather than bolted onto a decade of backward compatibility, but speed is a nice-to-have and atomicity is not.
# sync the remote index, then upgrade the system in one transaction
$ sudo xbps-install -Su
# search the remote repositories before installing anything
$ xbps-query -Rs compositor
# remove packages that nothing depends on any more
$ sudo xbps-remove -o
# verify the package database against what is actually on disk
$ xbps-pkgdb -aThe last two commands are the tell. Orphan cleanup and a database integrity check are not features anyone puts on a landing page. They exist because the people who built the tool run the thing they built, and at some point they wanted to ask the system whether it still matched its own records.
The second test: when do you pay for change
Every system pays for change. The only question is whether it pays continuously or in one lump.
Point releases feel safe. You freeze a snapshot, ship it, and tell yourself you have reduced risk. What you have actually done is defer it, and then pay it all at once during a giant version-bump migration that touches everything simultaneously.
A frozen base is genuinely the right answer for a fleet that must not move: a system inside a certification boundary, or one whose workload is validated against an exact set of versions. That is a real requirement and rolling would be the wrong answer for it. Anyone who tells you otherwise has not had to sign the paperwork.
It is the wrong answer for a system whose job is to stay current with the hardware and toolchains underneath it. A rolling base integrates change as a stream you can test against continuously, instead of a cliff you throw yourself off every two years. Paired with transactional installs, the unit of risk becomes one package at one moment, which is a size a person can actually reason about.
What rolling costs, plainly
- Rolling demands discipline from whoever maintains the system. Updates that reach users have to be tested first, and that burden never ends.
- There is no version number to certify against, which is a genuine blocker in environments that require one.
- "It worked yesterday" stops being a useful bug report, so you need to be able to say precisely what changed and to put it back.
The third point is what ties the two decisions together. A rolling model is only defensible on top of a package manager that rolls back cleanly. Choose one without the other and you have taken on the cost of both: continuous change with no undo.
The commitment, and its limits
0dyssey is being built to inherit xbps and a rolling base from Void, with its own UX layer above rather than a fork of what is underneath. That layer is the part we own, and the commitment we are willing to make in public is a criterion rather than a promise about speed: a package operation should be a transaction, and an update should be something you can undo.
There is no build to install yet, so nothing here is a benchmark or a report on a running machine. It is the decision, written down while it is still cheap to argue with, and it is written as a criterion on purpose. If a better package model appears that satisfies both tests, the criterion survives and the choice underneath it can change.