Remove header fragments which is not needd

This commit is contained in:
John Ericson 2022-08-04 14:02:38 -04:00
parent 016d7a8f78
commit 6f6498f59c
2 changed files with 8 additions and 8 deletions

View file

@ -26,7 +26,7 @@ Example:
|--------| |------------------------------| |----------| |--------| |------------------------------| |----------|
store directory digest name store directory digest name
## Store Directory {#store-directory} ## Store Directory
Every [store](./store.md) has a 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. 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. 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*. 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. > 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. 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. 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. 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. 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. If one knows content addressing was used, one can recalculate the reference and thus verify the store object.

View file

@ -25,7 +25,7 @@ Arrows indicate suggested reading order.
[ input addressing ] [ content addressing ] [ input addressing ] [ content addressing ]
``` ```
## Store Object {#store-object} ## Store Object
A store object can hold 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. 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]: 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. The only way to obtain references is by adding or building store objects.
A reference will always point to exactly one store object. A reference will always point to exactly one store object.
## Operations {#operations} ## Operations
A Nix store can *add*, *retrieve*, and *delete* store objects. 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' ] [ 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. 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. That allows processes to resolve references contained in files and thus access the contents of store objects.