nrabulinski/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity

add concrete store examples, reword note on file system

Browse source
This commit is contained in:
Valentin Gagarin 2022-04-28 01:15:27 +02:00
parent c8c1b705ad
commit 7b5c00f67f
1 changed files with 11 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
doc/manual/src/architecture/store/store.md
View file

@ -4,11 +4,18 @@ A Nix store is a collection of [store objects](objects.md) and associated operat
These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build plans.
Store objects are accessible in a file system through [store paths](paths.md).
Every store has a *store directory*, which contains that store’s objects and is a prefix of their store paths.
It defaults to `/nix/store`, but is in principle arbitrary.
A Nix store allows to add and retrieve store objects.
It can perform builds, that is, transform build inputs using instructions from the build plans into build outputs.
It also keeps track of *references* between data and can therefore garbage-collect unused store objects.
A Nix store can perform builds, that is, transform build inputs using instructions from the build plans into build outputs. It also keeps track of *references* between data and can therefore garbage-collect unused store objects.
There exist different types of stores, which all follow this model.
Examples:
- store on the local file system
- remote store accessible via SSH
- binary cache store accessible via HTTP
Every store with a file system representation has a *store directory*, which contains that store’s objects accessible through [store paths](paths.md).
The store directory defaults to `/nix/store`, but is in principle arbitrary.
## A Rosetta stone for the Nix store.