add subsections to table of contents

This commit is contained in:
Valentin Gagarin 2022-06-08 11:50:24 +02:00
parent c345345dee
commit def80d5777
2 changed files with 10 additions and 4 deletions

View file

@ -17,6 +17,12 @@
- [Upgrading Nix](installation/upgrading.md)
- [Architecture](architecture/architecture.md)
- [Store](architecture/store/store.md)
- [Store Object](architecture/store/store.md#store-object)
- [Reference](architecture/store/store.md#reference)
- [Operations](architecture/store/store.md#operations)
- [Closure](architecture/store/store.md#closure)
- [Files and Processes](architecture/store/store.md#files-and-processes)
- [Build system terminology](architecture/store/store.md#build-system-terminology)
- [Store Path](architecture/store/path.md)
- [Digest](architecture/store/path.md#digest)
- [Input Addressing](architecture/store/path.md#input-addressing)

View file

@ -36,13 +36,13 @@ Nix makes no distinction if store objects are build inputs, build results, or bu
Store objects are [immutable][immutable-object]: once created, they do not change until they are deleted.
## Reference
## Reference {#reference}
A store object reference is an [opaque][opaque-data-type], [unique identifier][unique-identifier]:
The only way to obtain references is by adding or building store objects.
A reference will always point to exactly one store object.
## Operations
## Operations {#operations}
A Nix store can *add*, *retrieve*, and *delete* store objects.
@ -178,7 +178,7 @@ Examples:
To make store objects accessible to processes, stores ultimately have to expose store objects through the file system.
## A [Rosetta stone][rosetta-stone] for build system terminology
## A [Rosetta stone][rosetta-stone] for build system terminology {#build-system-terminology}
The Nix store's design is comparable to other build systems.
Usage of terms is, for historic reasons, not entirely consistent within the Nix ecosystem, and still subject to slow change.