mirror of
https://github.com/NixOS/nix.git
synced 2025-11-11 13:06:01 +01:00
Merge remote-tracking branch 'origin/2.29-maintenance' into sync-2.29
This commit is contained in:
commit
8f7ac96bbc
5 changed files with 10 additions and 6 deletions
|
|
@ -20,8 +20,9 @@ prs: 1238
|
||||||
Here's one or more paragraphs that describe the change.
|
Here's one or more paragraphs that describe the change.
|
||||||
|
|
||||||
- It's markdown
|
- It's markdown
|
||||||
- Add references to the manual using @docroot@
|
- Add references to the manual using [links like this](@_at_docroot@/example.md)
|
||||||
```
|
```
|
||||||
|
<!-- for the raw markdown readers: that means using @docroot@ -->
|
||||||
|
|
||||||
Significant changes should add the following header, which moves them to the top.
|
Significant changes should add the following header, which moves them to the top.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -73,7 +73,7 @@ Derivations can declare some infrequently used optional attributes.
|
||||||
|
|
||||||
> **Warning**
|
> **Warning**
|
||||||
>
|
>
|
||||||
> If set to `true`, other advanced attributes such as [`allowedReferences`](#adv-attr-allowedReferences), [`allowedReferences`](#adv-attr-allowedReferences), [`allowedRequisites`](#adv-attr-allowedRequisites),
|
> If set to `true`, other advanced attributes such as [`allowedReferences`](#adv-attr-allowedReferences), [`allowedRequisites`](#adv-attr-allowedRequisites),
|
||||||
[`disallowedReferences`](#adv-attr-disallowedReferences) and [`disallowedRequisites`](#adv-attr-disallowedRequisites), maxSize, and maxClosureSize.
|
[`disallowedReferences`](#adv-attr-disallowedReferences) and [`disallowedRequisites`](#adv-attr-disallowedRequisites), maxSize, and maxClosureSize.
|
||||||
will have no effect.
|
will have no effect.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -23,7 +23,7 @@ The output spec for an output with a fixed content addresses additionally contai
|
||||||
> **Design note**
|
> **Design note**
|
||||||
>
|
>
|
||||||
> In principle, the output spec could also specify the references the store object should have, since the references and file system objects are equally parts of a content-addressed store object proper that contribute to its content-addressed.
|
> In principle, the output spec could also specify the references the store object should have, since the references and file system objects are equally parts of a content-addressed store object proper that contribute to its content-addressed.
|
||||||
> However, at this time, the references are not not done because all fixed content-addressed outputs are required to have no references (including no self-reference).
|
> However, at this time, the references are not done because all fixed content-addressed outputs are required to have no references (including no self-reference).
|
||||||
>
|
>
|
||||||
> Also in principle, rather than specifying the references and file system object data with separate hashes, a single hash that constraints both could be used.
|
> Also in principle, rather than specifying the references and file system object data with separate hashes, a single hash that constraints both could be used.
|
||||||
> This could be done with the final store path's digest, or better yet, the hash that will become the store path's digest before it is truncated.
|
> This could be done with the final store path's digest, or better yet, the hash that will become the store path's digest before it is truncated.
|
||||||
|
|
@ -116,7 +116,7 @@ Because the derivation output is not fixed (just like with [input addressing]),
|
||||||
> (The "environment", in this case, consists of attributes such as the Operating System Nix runs atop, along with the operating-system-specific privileges that Nix has been granted.
|
> (The "environment", in this case, consists of attributes such as the Operating System Nix runs atop, along with the operating-system-specific privileges that Nix has been granted.
|
||||||
> Because of how conventional operating systems like macos, Linux, etc. work, granting builders *fewer* privileges may ironically require that Nix be run with *more* privileges.)
|
> Because of how conventional operating systems like macos, Linux, etc. work, granting builders *fewer* privileges may ironically require that Nix be run with *more* privileges.)
|
||||||
|
|
||||||
That said, derivations producing floating content-addressed outputs may declare their builders as impure (like the builders of derivations producing producing fixed outputs).
|
That said, derivations producing floating content-addressed outputs may declare their builders as impure (like the builders of derivations producing fixed outputs).
|
||||||
This is provisionally supported as part of the [`impure-derivations`][xp-feature-impure-derivations] experimental feature.
|
This is provisionally supported as part of the [`impure-derivations`][xp-feature-impure-derivations] experimental feature.
|
||||||
|
|
||||||
### Compatibility negotiation
|
### Compatibility negotiation
|
||||||
|
|
@ -144,7 +144,7 @@ A *deterministic* content-addressing derivation should produce outputs with the
|
||||||
The choice of provisional store path can be thought of as an impurity, since it is an arbitrary choice.
|
The choice of provisional store path can be thought of as an impurity, since it is an arbitrary choice.
|
||||||
|
|
||||||
If provisional outputs paths are deterministically chosen, we are in the first branch of part (1).
|
If provisional outputs paths are deterministically chosen, we are in the first branch of part (1).
|
||||||
The builder the data it produces based on it in arbitrary ways, but this gets us closer to to [input addressing].
|
The builder the data it produces based on it in arbitrary ways, but this gets us closer to [input addressing].
|
||||||
Deterministically choosing the provisional path may be considered "complete sandboxing" by removing an impurity, but this is unsatisfactory
|
Deterministically choosing the provisional path may be considered "complete sandboxing" by removing an impurity, but this is unsatisfactory
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
|
|
|
||||||
|
|
@ -83,7 +83,7 @@ The rules for this are fairly concise:
|
||||||
|
|
||||||
- A content-addressing derivation may be pure or impure
|
- A content-addressing derivation may be pure or impure
|
||||||
|
|
||||||
- If it is impure, it may be be fixed (typical), or it may be floating if the additional [`impure-derivations`][xp-feature-impure-derivations] experimental feature is enabled.
|
- If it is impure, it may be fixed (typical), or it may be floating if the additional [`impure-derivations`][xp-feature-impure-derivations] experimental feature is enabled.
|
||||||
|
|
||||||
- If it is pure, it must be floating.
|
- If it is pure, it must be floating.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -57,6 +57,9 @@ def recursive_replace(data: dict[str, t.Any], book_root: Path, search_path: Path
|
||||||
).replace(
|
).replace(
|
||||||
'@docroot@',
|
'@docroot@',
|
||||||
("../" * len(path_to_chapter.parent.parts) or "./")[:-1]
|
("../" * len(path_to_chapter.parent.parts) or "./")[:-1]
|
||||||
|
).replace(
|
||||||
|
'@_at_',
|
||||||
|
'@'
|
||||||
),
|
),
|
||||||
sub_items = [
|
sub_items = [
|
||||||
recursive_replace(sub_item, book_root, search_path)
|
recursive_replace(sub_item, book_root, search_path)
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue