wroclaw-git-backups/nix
1
0
Fork 0
mirror of https://github.com/NixOS/nix synced 2025-06-25 10:41:16 +02:00
Code Activity

Fix minor documentation typos

Browse source 
Was reading the store chapter and came across a few small typos
and edits.
This commit is contained in:
Farid Zakaria 2025-03-07 23:07:03 -08:00
parent 47e23811ff
commit 33493b9ead
3 changed files with 8 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/manual/source/store/derivation/outputs/index.md
View file

@ -1,7 +1,7 @@
# Derivation Outputs and Types of Derivations # Derivation Outputs and Types of Derivations
As stated on the [main pages on derivations](../index.md#store-derivation), As stated on the [main pages on derivations](../index.md#store-derivation),
a derivation produces [store objects], which are known as the *outputs* of the derivation. a derivation produces [store objects](@docroot@/store/store-object.md), which are known as the *outputs* of the derivation.
Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducably produce these derivations each time the derivation is run. Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducably produce these derivations each time the derivation is run.
One of the parts of a derivation is its *outputs specification*, which specifies certain information about the outputs the derivation produces when run. One of the parts of a derivation is its *outputs specification*, which specifies certain information about the outputs the derivation produces when run.
@ -9,7 +9,7 @@ The outputs specification is a map, from names to specifications for individual
## Output Names {#outputs} ## Output Names {#outputs}
Output names can be any string which is also a valid [store path] name. Output names can be any string which is also a valid [store path](@docroot@/store/store-path.md) name.
The name mapped to each output specification is not actually the name of the output. The name mapped to each output specification is not actually the name of the output.
In the general case, the output store object has name `derivationName + "-" + outputSpecName`, not any other metadata about it. In the general case, the output store object has name `derivationName + "-" + outputSpecName`, not any other metadata about it.
However, an output spec named "out" describes and output store object whose name is just the derivation name. However, an output spec named "out" describes and output store object whose name is just the derivation name.
@ -24,11 +24,11 @@ However, an output spec named "out" describes and output store object whose name
> >
> - The store path of `dev` will be: `/nix/store/<hash>-hello-dev`. > - The store path of `dev` will be: `/nix/store/<hash>-hello-dev`.
The outputs are the derivations are the [store objects][store object] it is obligated to produce. The outputs are the derivations are the [store objects](@docroot@/store/store-object.md) it is obligated to produce.
> **Note** > **Note**
> >
> The formal terminology here is somewhat at adds with everyday communication in the Nix community today. > The formal terminology here is somewhat at odds with everyday communication in the Nix community today.
> "output" in casual usage tends to refer to either to the actual output store object, or the notional output spec, depending on context. > "output" in casual usage tends to refer to either to the actual output store object, or the notional output spec, depending on context.
> >
> For example "hello's `dev` output" means the store object referred to by the store path `/nix/store/<hash>-hello-dev`. > For example "hello's `dev` output" means the store object referred to by the store path `/nix/store/<hash>-hello-dev`.
@ -64,7 +64,7 @@ The rules for this are fairly concise:
(This is an arbitrary restriction that could be lifted.) (This is an arbitrary restriction that could be lifted.)
- The output is either *fixed* or *floating*, indicating whether the its store path is known prior to building it. - The output is either *fixed* or *floating*, indicating whether the store path is known prior to building it.
- With fixed content-addressing it is fixed. - With fixed content-addressing it is fixed.

3
doc/manual/source/store/file-system-object/content-address.md
View file

@ -46,7 +46,7 @@ be many different serialisations.
For these reasons, Nix has its very own archive format—the Nix Archive (NAR) format, For these reasons, Nix has its very own archive format—the Nix Archive (NAR) format,
which is carefully designed to avoid the problems described above. which is carefully designed to avoid the problems described above.
The exact specification of the Nix Archive format is in `protocols/nix-archive.md` The exact specification of the Nix Archive format is in [specified here](../../protocols/nix-archive.md).
## Content addressing File System Objects beyond a single serialisation pass ## Content addressing File System Objects beyond a single serialisation pass
@ -80,6 +80,7 @@ Thus, Git can encode some, but not all of Nix's "File System Objects", and this
In the future, we may support a Git-like hash for such file system objects, or we may adopt another Merkle DAG format which is capable of representing all Nix file system objects. In the future, we may support a Git-like hash for such file system objects, or we may adopt another Merkle DAG format which is capable of representing all Nix file system objects.
[file system object]: ../file-system-object.md [file system object]: ../file-system-object.md
[store object]: ../store-object.md [store object]: ../store-object.md
[xp-feature-git-hashing]: @docroot@/development/experimental-features.md#xp-feature-git-hashing [xp-feature-git-hashing]: @docroot@/development/experimental-features.md#xp-feature-git-hashing

2
doc/manual/source/store/store-object/content-address.md
View file

@ -50,7 +50,7 @@ The hashes of these modified input streams are used instead.
When validating the content address of a store object after the fact, the above process works as written. When validating the content address of a store object after the fact, the above process works as written.
However, when first creating the store object we don't know the store object's store path, as explained just above. However, when first creating the store object we don't know the store object's store path, as explained just above.
We therefore, strictly speaking, do not know what value we will be replacing with the sentinental value in the inputs to hash functions. We therefore, strictly speaking, do not know what value we will be replacing with the sentinel value in the inputs to hash functions.
What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was chosen when the data was created). What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was chosen when the data was created).
That provisional store path is instead what is replaced with the sentinel value, rather than the final store object which we do not yet know. That provisional store path is instead what is replaced with the sentinel value, rather than the final store object which we do not yet know.