aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJohn Ericson <John.Ericson@Obsidian.Systems>2022-08-04 14:02:38 -0400
committerJohn Ericson <John.Ericson@Obsidian.Systems>2022-08-04 14:02:38 -0400
commit6f6498f59c9263d3d4bdc6d2c3776e6abad2e516 (patch)
tree6f6fe173039ab13f4ce45e2bfe4e3b3bbb8643bb /doc
parent016d7a8f78bee2181d1d60bcf9a8a59a4f18e91f (diff)
Remove header fragments which is not needd
Diffstat (limited to 'doc')
-rw-r--r--doc/manual/src/architecture/store/path.md8
-rw-r--r--doc/manual/src/architecture/store/store.md8
2 files changed, 8 insertions, 8 deletions
diff --git a/doc/manual/src/architecture/store/path.md b/doc/manual/src/architecture/store/path.md
index 039d8b1c6..663f04f46 100644
--- a/doc/manual/src/architecture/store/path.md
+++ b/doc/manual/src/architecture/store/path.md
@@ -26,7 +26,7 @@ Example:
|--------| |------------------------------| |----------|
store directory digest name
-## Store Directory {#store-directory}
+## Store Directory
Every [store](./store.md) has a store directory.
@@ -53,7 +53,7 @@ One cannot copy a store object to a store with a different store directory.
Instead, it has to be rebuilt, together with all its dependencies.
It is in general not enough to replace the store directory string in file contents, as this may render executables unusable by invalidating their internal offsets or checksums.
-# Digest {#digest}
+# Digest
In a [store path](#store-path), the [digest][digest] is the output of a [cryptographic hash function][hash] of either all *inputs* involved in building the referenced store object or its actual *contents*.
@@ -84,7 +84,7 @@ This depends on the specifics of the software to build and run.
>
> For example, Java programs are compressed after compilation, which obfuscates any store paths they may refer to and prevents Nix from automatically detecting them.
-## Input Addressing {#input-addressing}
+## Input Addressing
Input addressing means that the digest derives from how the store object was produced, namely its build inputs and build plan.
@@ -95,7 +95,7 @@ Nix has a custom serialisation format called Nix Archive (NAR)
Store object references of this sort can *not* be validated from the content of the store object.
Rather, a cryptographic signature has to be used to indicate that someone is vouching for the store object really being produced from a build plan with that digest.
-## Content Addressing {#content-addressing}
+## Content Addressing
Content addressing means that the digest derives from the store object's contents, namely its file system objects and references.
If one knows content addressing was used, one can recalculate the reference and thus verify the store object.
diff --git a/doc/manual/src/architecture/store/store.md b/doc/manual/src/architecture/store/store.md
index 9f580f9da..08b6701d5 100644
--- a/doc/manual/src/architecture/store/store.md
+++ b/doc/manual/src/architecture/store/store.md
@@ -25,7 +25,7 @@ Arrows indicate suggested reading order.
[ input addressing ] [ content addressing ]
```
-## Store Object {#store-object}
+## Store Object
A store object can hold
@@ -36,13 +36,13 @@ Store objects can be build inputs, build results, or build tasks.
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.
@@ -89,7 +89,7 @@ As it keeps track of references, it can [garbage-collect][garbage-collection] un
[ store ] --> collect garbage --> [ store' ]
-## Files and Processes {#files-and-processes}
+## Files and Processes
Nix maps between its store model and the [Unix paradigm][unix-paradigm] of [files and processes][file-descriptor], by encoding immutable store objects and opaque identifiers as file system primitives: files and directories, and paths.
That allows processes to resolve references contained in files and thus access the contents of store objects.