Rename to "content-address*ing* derivation"

"content-address*ed*" derivation is misleading because all derivations
are *themselves* content-addressed. What may or may not be
content-addressed is not derivation itself, but the *output* of the
derivation.

The outputs are not *part* of the derivation (for then the derivation
wouldn't be complete before we built it) but rather separate entities
produced by the derivation.

"content-adddress*ed*" is not correctly because it can only describe
what the derivation *is*, and that is not what we are trying to do.

"content-address*ing*" is correct because it describes what the
derivation *does* --- it produces content-addressed data.

doc/manual/redirects.js

@@ -375,6 +375,7 @@ const redirects = {
   "glossary.html": {
     "gloss-local-store": "store/types/local-store.html",
     "gloss-chroot-store": "store/types/local-store.html",
+    "gloss-content-addressed-derivation": "#gloss-content-addressing-derivation",
   },
 };
 

doc/manual/source/command-ref/nix-store/realise.md

@@ -15,7 +15,7 @@ Each of *paths* is processed as follows:
   1. If it is not [valid], substitute the store derivation file itself.
   2. Realise its [output paths]:
     - Try to fetch from [substituters] the [store objects] associated with the output paths in the store derivation's [closure].
-      - With [content-addressed derivations] (experimental):
+      - With [content-addressing derivations] (experimental):
         Determine the output paths to realise by querying content-addressed realisation entries in the [Nix database].
     - For any store paths that cannot be substituted, produce the required store objects:
       1. Realise all outputs of the derivation's dependencies
@@ -32,7 +32,7 @@ If no substitutes are available and no store derivation is given, realisation fa
 [store objects]: @docroot@/store/store-object.md
 [closure]: @docroot@/glossary.md#gloss-closure
 [substituters]: @docroot@/command-ref/conf-file.md#conf-substituters
-[content-addressed derivations]: @docroot@/development/experimental-features.md#xp-feature-ca-derivations
+[content-addressing derivations]: @docroot@/development/experimental-features.md#xp-feature-ca-derivations
 [Nix database]: @docroot@/glossary.md#gloss-nix-database
 
 The resulting paths are printed on standard output.

doc/manual/source/development/testing.md

@@ -164,7 +164,7 @@ $ checkPhase
 
 Sometimes it is useful to group related tests so they can be easily run together without running the entire test suite.
 Each test group is in a subdirectory of `tests`.
-For example, `tests/functional/ca/meson.build` defines a `ca` test group for content-addressed derivation outputs.
+For example, `tests/functional/ca/meson.build` defines a `ca` test group for content-addressing derivation outputs.
 
 That test group can be run like this:
 

doc/manual/source/glossary.md

@@ -13,7 +13,7 @@
 
     - [Content-Addressing File System Objects](@docroot@/store/file-system-object/content-address.md)
     - [Content-Addressing Store Objects](@docroot@/store/store-object/content-address.md)
-    - [content-addressed derivation](#gloss-content-addressed-derivation)
+    - [content-addressing derivation](#gloss-content-addressing-derivation)
 
   Software Heritage's writing on [*Intrinsic and Extrinsic identifiers*](https://www.softwareheritage.org/2020/07/09/intrinsic-vs-extrinsic-identifiers) is also a good introduction to the value of content-addressing over other referencing schemes.
 
@@ -69,7 +69,7 @@
 
   [realise]: #gloss-realise
 
-- [content-addressed derivation]{#gloss-content-addressed-derivation}
+- [content-addressing derivation]{#gloss-content-addressing-derivation}
 
   A derivation which has the
   [`__contentAddressed`](./language/advanced-attributes.md#adv-attr-__contentAddressed)
@@ -134,7 +134,7 @@
 - [input-addressed store object]{#gloss-input-addressed-store-object}
 
   A store object produced by building a
-  non-[content-addressed](#gloss-content-addressed-derivation),
+  non-[content-addressed](#gloss-content-addressing-derivation),
   non-[fixed-output](#gloss-fixed-output-derivation)
   derivation.
 
@@ -142,7 +142,7 @@
 
   A [store object] which is [content-addressed](#gloss-content-address),
   i.e. whose [store path] is determined by its contents.
-  This includes derivations, the outputs of [content-addressed derivations](#gloss-content-addressed-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
+  This includes derivations, the outputs of [content-addressing derivations](#gloss-content-addressing-derivation), and the outputs of [fixed-output derivations](#gloss-fixed-output-derivation).
 
   See [Content-Addressing Store Objects](@docroot@/store/store-object/content-address.md) for details.
 

doc/manual/source/store/drv.md

@@ -68,7 +68,7 @@ type OutputPath = {
 type DerivingPath = ConstantPath | OutputPath;
 ```
 
-Deriving paths are necessary because, in general and particularly for [content-addressed derivations][content-addressed derivation], the [store path] of an [output] is not known in advance.
+Deriving paths are necessary because, in general and particularly for [content-addressing derivations][content-addressing derivation], the [store path] of an [output] is not known in advance.
 We can use an output deriving path to refer to such an out, instead of the store path which we do not yet know.
 
 [deriving path]: #deriving-path
@@ -122,7 +122,7 @@ Nix can schedule builds such that it automatically builds on other platforms by
 
 [`system` configuration option]: @docroot@/command-ref/conf-file.md#conf-system
 
-[content-addressed derivation]: @docroot@/glossary.md#gloss-content-addressed-derivation
+[content-addressing derivation]: @docroot@/glossary.md#gloss-content-addressing-derivation
 [realise]: @docroot@/glossary.md#gloss-realise
 [store object]: @docroot@/store/store-object.md
 [store path]: @docroot@/store/store-path.md