move package-management/terminology into glossary.md

This commit is contained in:
Adam Joseph 2022-08-05 10:39:43 -07:00
parent 4de95f7f56
commit 1d3b92e80c
3 changed files with 37 additions and 37 deletions

View file

@ -22,7 +22,6 @@
- [Garbage Collector Roots](package-management/garbage-collector-roots.md)
- [Channels](package-management/channels.md)
- [Sharing Packages Between Machines](package-management/sharing-packages.md)
- [Terminology](package-management/terminology.md)
- [Serving a Nix store via HTTP](package-management/binary-cache-substituter.md)
- [Copying Closures via SSH](package-management/copy-closure.md)
- [Serving a Nix store via SSH](package-management/ssh-substituter.md)

View file

@ -11,6 +11,32 @@
The location in the file system where store objects live. Typically
`/nix/store`.
From the perspective of the location where Nix is
invoked<sup><b>1</b></sup>, the Nix store can be referred to
as a "_local_" or a "_remote_" one:
<sup>\[1]: Where "invoking Nix" means an executing a Nix core
action/operation on a Nix store. For example, using any CLI
commands from the `NixOS/nix` implementation.</sup>
+ A *local store* exists on the local filesystem of
the machine where Nix is invoked. You can use other
local stores by passing the `--store` flag to the
`nix` command.
+ A *remote store* exists anywhere other than the
local filesystem. One example is the `/nix/store`
directory on another machine, accessed via `ssh` or
served by the `nix-serve` Perl script.
- [binary cache]{#binary-cache}\
A *binary cache* is a Nix store which uses a different format: its
metadata and signatures are kept in `.narinfo` files rather than in a
Nix database. This different format simplifies serving store objects
over the network, but cannot host builds. Examples of binary caches
include S3 buckets and the [NixOS binary
cache](https://cache.nixos.org).
- [store path]{#gloss-store-path}\
The location in the file system of a store object, i.e., an
immediate child of the Nix store directory.
@ -29,6 +55,17 @@
store object by downloading a pre-built version of the store object
from some server.
- [substituter]{#gloss-substituter}\
A *substituter* is a store other than `/nix/store` from which Nix will
copy a store path instead of building it. Nix will not copy a store
path from a remote store unless one of the following is true:
- the store object is signed by one of the `trusted-public-keys`
- the substituter is in the `trusted-substituters` list
- the `no-require-sigs` option has been set to disable signature checking
- the store object is a derivation
- the store object is the realisation of a fixed-output derivation
- [purity]{#gloss-purity}\
The assumption that equal Nix derivations when run always produce
the same output. This cannot be guaranteed in general (e.g., a

View file

@ -1,36 +0,0 @@
# Terminology
From the perspective of the location where Nix is
invoked<sup><b>1</b></sup>, the Nix store can be referred to
as a "_local_" or a "_remote_" one:
<sup>\[1]: Where "invoking Nix" means an executing a Nix core
action/operation on a Nix store. For example, using any CLI
commands from the `NixOS/nix` implementation.</sup>
+ A *local store* exists on the local filesystem of
the machine where Nix is invoked. You can use other
local stores by passing the `--store` flag to the
`nix` command.
+ A *remote store* exists anywhere other than the
local filesystem. One example is the `/nix/store`
directory on another machine, accessed via `ssh` or
served by the `nix-serve` Perl script.
A *binary cache* is a Nix store which uses a different format: its
metadata and signatures are kept in `.narinfo` files rather than in a
Nix database. This different format simplifies serving store objects
over the network, but cannot host builds. Examples of binary caches
include S3 buckets and the [NixOS binary
cache](https://cache.nixos.org).
A *substituter* is a store other than `/nix/store` from which Nix will
copy a store path instead of building it. Nix will not copy a store
path from a remote store unless one of the following is true:
- the store object is signed by one of the `trusted-public-keys`
- the substituter is in the `trusted-substituters` list
- the `no-require-sigs` option has been set to disable signature checking
- the store object is a derivation
- the store object is the realisation of a fixed-output derivation