7.1 Atomicity
Package transactions coordinate recorded package state and changes to files. That does not make all filesystem changes, every root's database, and post-commit maintenance one instantaneous switch.
For the cross-root path reviewed in peipkg 8b588ae8:
- Packages for all participants are fetched and verified before extraction.
- Preparing roots persists recovery data and moves files into place. Those files can become visible before a root's package-state commit.
- Package state commits separately in each root. A commit failure can leave some roots committed and others pending; already committed roots are not undone by rolling back a sibling.
- A preparation rollback can itself fail, leaving a pending journal and files that must not be treated as restored.
These boundaries follow the coordinated execution sequence, preparation and per-root commit, and rollback-error handling. Logical errors, power loss or other system faults therefore require checking the actual journal and files. The older blanket promises that uncommitted work is invisible and partial effects never occur do not describe this path.
7.1.1 The single durability boundary #
Within one root, updating package metadata and closing that root's journal transaction share a single database transaction. Its database commit is that root's durability boundary. It is not a global cross-root commit.
A pending cross-root journal does not by itself determine recovery direction: if none of the participants committed, recovery rolls pending work back; after a participant commits, recovery rolls pending siblings forward using persisted completion data. Missing data or another failure can prevent completion. See Crash recovery.
The source qualification here does not verify every single-root failure path or the revision shipped in an installed image. Use the operator recovery checks and visibility limits before treating a failed or interrupted operation as unchanged, restored or ready to use.