forked from lix-project/lix
use correct mdBook syntax for callouts
This commit is contained in:
parent
8cec32e7f5
commit
cc3a5f4ba2
|
@ -34,10 +34,9 @@ It is used to compose expressions which ultimately evaluate to self-contained *b
|
||||||
|
|
||||||
The command line and Nix language are what users interact with most.
|
The command line and Nix language are what users interact with most.
|
||||||
|
|
||||||
::: {.note}
|
> **Note**
|
||||||
The Nix language itself does not have a notion of *packages* or *configurations*.
|
> The Nix language itself does not have a notion of *packages* or *configurations*.
|
||||||
As far as we are concerned here, the inputs and results of a build plan are just data.
|
> As far as we are concerned here, the inputs and results of a build plan are just data.
|
||||||
:::
|
|
||||||
|
|
||||||
Underlying these is the [Nix store](./store/store.md), a mechanism to keep track of build plans, data, and references between them.
|
Underlying these is the [Nix store](./store/store.md), a mechanism to keep track of build plans, data, and references between them.
|
||||||
It can also execute build plans to produce new data.
|
It can also execute build plans to produce new data.
|
||||||
|
|
|
@ -34,9 +34,8 @@ If the store has a [file system representation](./store.md#files-and-processes),
|
||||||
|
|
||||||
This means a store path is not just derived from the referenced store object itself, but depends on the store the store object is in.
|
This means a store path is not just derived from the referenced store object itself, but depends on the store the store object is in.
|
||||||
|
|
||||||
::: {.note}
|
> **Note**
|
||||||
The store directory defaults to `/nix/store`, but is in principle arbitrary.
|
> The store directory defaults to `/nix/store`, but is in principle arbitrary.
|
||||||
:::
|
|
||||||
|
|
||||||
It is important which store a given store object belongs to:
|
It is important which store a given store object belongs to:
|
||||||
Files in the store object can contain store paths, and processes may read these paths.
|
Files in the store object can contain store paths, and processes may read these paths.
|
||||||
|
@ -60,10 +59,9 @@ In a [store path](#store-path), the [digest][digest] is the output of a [cryptog
|
||||||
|
|
||||||
Store objects are therefore said to be either [input-addressed](#input-addressing) or [content-addressed](#content-addressing).
|
Store objects are therefore said to be either [input-addressed](#input-addressing) or [content-addressed](#content-addressing).
|
||||||
|
|
||||||
::: {.note}
|
> **Historical Note**
|
||||||
**Historical note**: The 20 byte restriction is because originally digests were [SHA-1][sha-1] hashes.
|
> The 20 byte restriction is because originally digests were [SHA-1][sha-1] hashes.
|
||||||
Nix now uses [SHA-256][sha-256], and longer hashes are still reduced to 20 bytes for compatibility.
|
> Nix now uses [SHA-256][sha-256], and longer hashes are still reduced to 20 bytes for compatibility.
|
||||||
:::
|
|
||||||
|
|
||||||
[digest]: https://en.m.wiktionary.org/wiki/digest#Noun
|
[digest]: https://en.m.wiktionary.org/wiki/digest#Noun
|
||||||
[hash]: https://en.m.wikipedia.org/wiki/Cryptographic_hash_function
|
[hash]: https://en.m.wikipedia.org/wiki/Cryptographic_hash_function
|
||||||
|
@ -80,12 +78,11 @@ Nix uses the [closure](store.md#closure) of build inputs to derive the list of a
|
||||||
This way, scanning files captures run time dependencies without the user having to declare them explicitly.
|
This way, scanning files captures run time dependencies without the user having to declare them explicitly.
|
||||||
Doing it at build time and persisting references in the store object avoids repeating this time-consuming operation.
|
Doing it at build time and persisting references in the store object avoids repeating this time-consuming operation.
|
||||||
|
|
||||||
::: {.note}
|
> **Note**
|
||||||
In practice, it is sometimes still necessary for users to declare certain dependencies explicitly, if they are to be preserved in the build result's closure.
|
> In practice, it is sometimes still necessary for users to declare certain dependencies explicitly, if they are to be preserved in the build result's closure.
|
||||||
This depends on the specifics of the software to build and run.
|
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}
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue