diff options
author | Andrew <Andrew@Kvalhe.im> | 2023-06-10 17:15:43 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-06-11 02:15:43 +0200 |
commit | 1b6f6406878da49a667a774d842f7e3aa6a84768 (patch) | |
tree | a9dc681d322fd5bcd2bdc46096de8c37b1d3dc4d /doc/stdenv | |
parent | 30a6ecff17bc023b5f894d3a11866495e6d8c17a (diff) |
doc: correct typos and spelling (#237098)
Diffstat (limited to 'doc/stdenv')
-rw-r--r-- | doc/stdenv/meta.chapter.md | 2 | ||||
-rw-r--r-- | doc/stdenv/stdenv.chapter.md | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/doc/stdenv/meta.chapter.md b/doc/stdenv/meta.chapter.md index a21dfd0821af5..0cb2d6573dfc5 100644 --- a/doc/stdenv/meta.chapter.md +++ b/doc/stdenv/meta.chapter.md @@ -70,7 +70,7 @@ A list of the maintainers of this Nix expression. Maintainers are defined in [`n ### `mainProgram` {#var-meta-mainProgram} -The name of the main binary for the package. This effects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"` +The name of the main binary for the package. This affects the binary `nix run` executes and falls back to the name of the package. Example: `"rg"` ### `priority` {#var-meta-priority} diff --git a/doc/stdenv/stdenv.chapter.md b/doc/stdenv/stdenv.chapter.md index a923da935ced6..0b3776b530ca6 100644 --- a/doc/stdenv/stdenv.chapter.md +++ b/doc/stdenv/stdenv.chapter.md @@ -286,7 +286,7 @@ This is where “sum-like” comes in from above: We can just sum all of the hos Because of the bounds checks, the uncommon cases are `h = t` and `h + 2 = t`. In the former case, the motivation for `mapOffset` is that since its host and target platforms are the same, no transitive dependency of it should be able to “discover” an offset greater than its reduced target offsets. `mapOffset` effectively “squashes” all its transitive dependencies’ offsets so that none will ever be greater than the target offset of the original `h = t` package. In the other case, `h + 1` is skipped over between the host and target offsets. Instead of squashing the offsets, we need to “rip” them apart so no transitive dependencies’ offset is that one. -Overall, the unifying theme here is that propagation shouldn’t be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the dependending package asking for dependencies with the platforms it knows about; other platforms it doesn’t know how to ask for. The platform description in that scenario is a kind of unforagable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms weren’t in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency. +Overall, the unifying theme here is that propagation shouldn’t be introducing transitive dependencies involving platforms the depending package is unaware of. \[One can imagine the depending package asking for dependencies with the platforms it knows about; other platforms it doesn’t know how to ask for. The platform description in that scenario is a kind of unforgeable capability.\] The offset bounds checking and definition of `mapOffset` together ensure that this is the case. Discovering a new offset is discovering a new platform, and since those platforms weren’t in the derivation “spec” of the needing package, they cannot be relevant. From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency. #### Variables specifying dependencies {#variables-specifying-dependencies} |