mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-10 08:16:15 +02:00
Remove header fragments which is not needd
This commit is contained in:
parent
016d7a8f78
commit
6f6498f59c
2 changed files with 8 additions and 8 deletions
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue