mirror of
https://github.com/NixOS/nix
synced 2025-06-24 22:11:15 +02:00
Merge remote-tracking branch 'upstream/master' into rl-next
This commit is contained in:
John Ericson
commit
18894c934f
18 changed files with 56 additions and 39 deletions
|
|
@ -14,7 +14,7 @@ import sys
|
|||
# literally. since the rules for these aren't even the same for
|
||||
# all three we will just fail when we encounter any of them (if
|
||||
# asserts are off for some reason the depfile will likely point
|
||||
# to nonexistant paths, making everything phony and thus fine.)
|
||||
# to nonexistent paths, making everything phony and thus fine.)
|
||||
for path in glob.glob(sys.argv[1] + '/**', recursive=True):
|
||||
assert '\\' not in path
|
||||
assert ' ' not in path
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ subdir('source/release-notes')
|
|||
subdir('source')
|
||||
|
||||
# Hacky way to figure out if `nix` is an `ExternalProgram` or
|
||||
# `Exectuable`. Only the latter can occur in custom target input lists.
|
||||
# `Executable`. Only the latter can occur in custom target input lists.
|
||||
if nix.full_path().startswith(meson.build_root())
|
||||
nix_input = nix
|
||||
else
|
||||
|
|
|
|||
|
|
@ -11,6 +11,8 @@
|
|||
python3,
|
||||
rsync,
|
||||
nix-cli,
|
||||
changelog-d,
|
||||
officialRelease,
|
||||
|
||||
# Configuration Options
|
||||
|
||||
|
|
@ -44,16 +46,24 @@ mkMesonDerivation (finalAttrs: {
|
|||
];
|
||||
|
||||
# Hack for sake of the dev shell
|
||||
passthru.externalNativeBuildInputs = [
|
||||
meson
|
||||
ninja
|
||||
(lib.getBin lowdown-unsandboxed)
|
||||
mdbook
|
||||
mdbook-linkcheck
|
||||
jq
|
||||
python3
|
||||
rsync
|
||||
];
|
||||
passthru.externalNativeBuildInputs =
|
||||
[
|
||||
meson
|
||||
ninja
|
||||
(lib.getBin lowdown-unsandboxed)
|
||||
mdbook
|
||||
mdbook-linkcheck
|
||||
jq
|
||||
python3
|
||||
rsync
|
||||
changelog-d
|
||||
]
|
||||
++ lib.optionals (!officialRelease) [
|
||||
# When not an official release, we likely have changelog entries that have
|
||||
# yet to be rendered.
|
||||
# When released, these are rendered into a committed file to save a dependency.
|
||||
changelog-d
|
||||
];
|
||||
|
||||
nativeBuildInputs = finalAttrs.passthru.externalNativeBuildInputs ++ [
|
||||
nix-cli
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ This operation deletes the specified generations of the current profile.
|
|||
>
|
||||
> Older *and newer* generations will be deleted by this operation.
|
||||
>
|
||||
> One might expect this to just delete older generations than the curent one, but that is only true if the current generation is also the latest.
|
||||
> One might expect this to just delete older generations than the current one, but that is only true if the current generation is also the latest.
|
||||
> Because one can roll back to a previous generation, it is possible to have generations newer than the current one.
|
||||
> They will also be deleted.
|
||||
|
||||
|
|
|
|||
|
|
@ -195,19 +195,25 @@ Nix uses a string with the following format to identify the *system type* or *pl
|
|||
<cpu>-<os>[-<abi>]
|
||||
```
|
||||
|
||||
It is set when Nix is compiled for the given system, and based on the output of [`config.guess`](https://github.com/nixos/nix/blob/master/config/config.guess) ([upstream](https://git.savannah.gnu.org/cgit/config.git/tree/config.guess)):
|
||||
It is set when Nix is compiled for the given system, and based on the output of Meson's [`host_machine` information](https://mesonbuild.com/Reference-manual_builtin_host_machine.html)>
|
||||
|
||||
```
|
||||
<cpu>-<vendor>-<os>[<version>][-<abi>]
|
||||
```
|
||||
|
||||
When Nix is built such that `./configure` is passed any of the `--host`, `--build`, `--target` options, the value is based on the output of [`config.sub`](https://github.com/nixos/nix/blob/master/config/config.sub) ([upstream](https://git.savannah.gnu.org/cgit/config.git/tree/config.sub)):
|
||||
When cross-compiling Nix with Meson for local development, you need to specify a [cross-file](https://mesonbuild.com/Cross-compilation.html) using the `--cross-file` option. Cross-files define the target architecture and toolchain. When cross-compiling Nix with Nix, Nixpkgs takes care of this for you.
|
||||
|
||||
In the nix flake we also have some cross-compilation targets available:
|
||||
|
||||
```
|
||||
<cpu>-<vendor>[-<kernel>]-<os>
|
||||
nix build .#nix-everything-riscv64-unknown-linux-gnu
|
||||
nix build .#nix-everything-armv7l-unknown-linux-gnueabihf
|
||||
nix build .#nix-everything-armv7l-unknown-linux-gnueabihf
|
||||
nix build .#nix-everything-x86_64-unknown-freebsd
|
||||
nix build .#nix-everything-x86_64-w64-mingw32
|
||||
```
|
||||
|
||||
For historic reasons and backward-compatibility, some CPU and OS identifiers are translated from the GNU Autotools naming convention in [`configure.ac`](https://github.com/nixos/nix/blob/master/configure.ac) as follows:
|
||||
For historic reasons and backward-compatibility, some CPU and OS identifiers are translated as follows:
|
||||
|
||||
| `config.guess` | Nix |
|
||||
|----------------------------|---------------------|
|
||||
|
|
@ -230,18 +236,18 @@ Nix can be compiled using multiple environments:
|
|||
To build with one of those environments, you can use
|
||||
|
||||
```console
|
||||
$ nix build .#nix-ccacheStdenv
|
||||
$ nix build .#nix-cli-ccacheStdenv
|
||||
```
|
||||
|
||||
for flake-enabled Nix, or
|
||||
|
||||
```console
|
||||
$ nix-build --attr nix-ccacheStdenv
|
||||
$ nix-build --attr nix-cli-ccacheStdenv
|
||||
```
|
||||
|
||||
for classic Nix.
|
||||
|
||||
You can use any of the other supported environments in place of `nix-ccacheStdenv`.
|
||||
You can use any of the other supported environments in place of `nix-cli-ccacheStdenv`.
|
||||
|
||||
## Editor integration
|
||||
|
||||
|
|
|
|||
|
|
@ -170,9 +170,9 @@ sensitive.
|
|||
|
||||
|
||||
```shell
|
||||
$ nix init --template=template#pyton
|
||||
$ nix init --template=template#python
|
||||
------------------------------------------------------------------------
|
||||
Error! Template `template#pyton` not found.
|
||||
Error! Template `template#python` not found.
|
||||
------------------------------------------------------------------------
|
||||
Initializing Nix project at `/path/to/here`.
|
||||
Select a template for you new project:
|
||||
|
|
|
|||
|
|
@ -343,7 +343,7 @@
|
|||
|
||||
See [Nix Archive](store/file-system-object/content-address.html#serial-nix-archive) for details.
|
||||
|
||||
- [`∅`]{#gloss-emtpy-set}
|
||||
- [`∅`]{#gloss-empty-set}
|
||||
|
||||
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ The purpose of string contexts is to collect non-string values attached to strin
|
|||
[string interpolation](./string-interpolation.md),
|
||||
and similar operations.
|
||||
The idea is that a user can reference other files when creating text files through Nix expressions, without manually keeping track of the exact paths.
|
||||
Nix will ensure that the all referenced files are accessible – that all [store paths](@docroot@/glossary.md#gloss-store-path) are [valid](@docroot@/glossary.md#gloss-validitiy).
|
||||
Nix will ensure that the all referenced files are accessible – that all [store paths](@docroot@/glossary.md#gloss-store-path) are [valid](@docroot@/glossary.md#gloss-validity).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ is a JSON object with the following fields:
|
|||
|
||||
|
||||
* `method`:
|
||||
For an output which will be [content addresed], a string representing the [method](@docroot@/store/store-object/content-address.md) of content addressing that is chosen.
|
||||
For an output which will be [content addressed], a string representing the [method](@docroot@/store/store-object/content-address.md) of content addressing that is chosen.
|
||||
Valid method strings are:
|
||||
|
||||
- [`flat`](@docroot@/store/store-object/content-address.md#method-flat)
|
||||
|
|
@ -35,7 +35,7 @@ is a JSON object with the following fields:
|
|||
Otherwise, `null`.
|
||||
|
||||
* `hashAlgo`:
|
||||
For an output which will be [content addresed], the name of the hash algorithm used.
|
||||
For an output which will be [content addressed], the name of the hash algorithm used.
|
||||
Valid algorithm strings are:
|
||||
|
||||
- `blake3`
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ defined as the timestamp of the newest file inside the tarball.
|
|||
This protocol is supported by Gitea since v1.22.1 and by Forgejo since v7.0.4/v8.0.0 and can be used with the following flake URL schema:
|
||||
|
||||
```
|
||||
https://<domain name>/<owner>/<repo>/archive/<reference or revison>.tar.gz
|
||||
https://<domain name>/<owner>/<repo>/archive/<reference or revision>.tar.gz
|
||||
```
|
||||
|
||||
> **Example**
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@
|
|||
- To operate on a flake outside the current directory, you must now pass `--flake path/to/flake`.
|
||||
|
||||
- The flake-specific flags `--recreate-lock-file` and `--update-input` have been removed from all commands operating on installables.
|
||||
They are superceded by `nix flake update`.
|
||||
They are superseded by `nix flake update`.
|
||||
|
||||
- Commit signature verification for the [`builtins.fetchGit`](@docroot@/language/builtins.md#builtins-fetchGit) is added as the new [`verified-fetches` experimental feature](@docroot@/development/experimental-features.md#xp-feature-verified-fetches).
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
- Modify `nix derivation {add,show}` JSON format [#9866](https://github.com/NixOS/nix/issues/9866) [#10722](https://github.com/NixOS/nix/pull/10722)
|
||||
|
||||
The JSON format for derivations has been slightly revised to better conform to our [JSON guidelines](@docroot@/development/cli-guideline.md#returning-future-proof-json).
|
||||
In particular, the hash algorithm and content addressing method of content-addresed derivation outputs are now separated into two fields `hashAlgo` and `method`,
|
||||
In particular, the hash algorithm and content addressing method of content-addressed derivation outputs are now separated into two fields `hashAlgo` and `method`,
|
||||
rather than one field with an arcane `:`-separated format.
|
||||
|
||||
This JSON format is only used by the experimental `nix derivation` family of commands, at this time.
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@
|
|||
**Deprecation**: Use `nix32` instead of `base32` as `toHashFormat`
|
||||
|
||||
For the builtin `convertHash`, the `toHashFormat` parameter now accepts the same hash formats as the `--to`/`--from`
|
||||
parameters of the `nix hash conert` command: `"base16"`, `"nix32"`, `"base64"`, and `"sri"`. The former `"base32"` value
|
||||
parameters of the `nix hash convert` command: `"base16"`, `"nix32"`, `"base64"`, and `"sri"`. The former `"base32"` value
|
||||
remains as a deprecated alias for `"nix32"`. Please convert your code from:
|
||||
|
||||
```nix
|
||||
|
|
|
|||
|
|
@ -110,18 +110,18 @@ Because the derivation output is not fixed (just like with [input addressing]),
|
|||
>
|
||||
> Strictly speaking, the extent to which sandboxing and deprivilaging is possible varies with the environment Nix is running in.
|
||||
> Nix's configuration settings indicate what level of sandboxing is required or enabled.
|
||||
> Builds of derivations will fail if they request an absense of sandboxing which is not allowed.
|
||||
> Builds of derivations will also fail if the level of sandboxing specified in the configure exceeds what is possible in teh given environment.
|
||||
> Builds of derivations will fail if they request an absence of sandboxing which is not allowed.
|
||||
> Builds of derivations will also fail if the level of sandboxing specified in the configure exceeds what is possible in the given environment.
|
||||
>
|
||||
> (The "environment", in this case, consists of attributes such as the Operating System Nix runs atop, along with the operating-system-specific privilages that Nix has been granted.
|
||||
> Because of how conventional operating systems like macos, Linux, etc. work, granting builders *fewer* privilages may ironically require that Nix be run with *more* privilages.)
|
||||
> (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.)
|
||||
|
||||
That said, derivations producing floating content-addressed outputs may declare their builders as impure (like the builders of derivations producing producing fixed outputs).
|
||||
This is provisionally supported as part of the [`impure-derivations`][xp-feature-impure-derivations] experimental feature.
|
||||
|
||||
### Compatibility negotiation
|
||||
|
||||
Any derivation producing a floating content-addresssed output implicitly requires the `ca-derivations` [system feature](@docroot@/command-ref/conf-file.md#conf-system-features).
|
||||
Any derivation producing a floating content-addressed output implicitly requires the `ca-derivations` [system feature](@docroot@/command-ref/conf-file.md#conf-system-features).
|
||||
This prevents scheduling the building of the derivation on a machine without the experimental feature enabled.
|
||||
Even once the experimental feature is stabilized, this is still useful in order to be allow using remote builder running odler versions of Nix, or alternative implementations that do not support floating content addressing.
|
||||
|
||||
|
|
@ -132,7 +132,7 @@ For store objects produced by manually inserting into the store to create a stor
|
|||
But for store objects produced by derivation, the "method is quite formal" --- the whole point of derivations is to be a formal notion of building, after all.
|
||||
In this case, we can elevate this informal property to a formal one.
|
||||
|
||||
A *determinstic* content-addressing derivation should produce outputs with the same content addresses:
|
||||
A *deterministic* content-addressing derivation should produce outputs with the same content addresses:
|
||||
|
||||
1. Every time the builder is run
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
As stated on the [main pages on derivations](../index.md#store-derivation),
|
||||
a derivation produces [store objects](@docroot@/store/store-object.md), which are known as the *outputs* of the derivation.
|
||||
Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducably produce these derivations each time the derivation is run.
|
||||
Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducibly produce these derivations each time the derivation is run.
|
||||
|
||||
One of the parts of a derivation is its *outputs specification*, which specifies certain information about the outputs the derivation produces when run.
|
||||
The outputs specification is a map, from names to specifications for individual outputs.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ The *referrers* of a store object are the store objects that reference it.
|
|||
|
||||
[transpose graph]: https://en.wikipedia.org/wiki/Transpose_graph
|
||||
|
||||
One can also combine both concepts: taking the transitive closure of the tranposed references graph.
|
||||
One can also combine both concepts: taking the transitive closure of the transposed references graph.
|
||||
The *referrers closure* of a store object are the store objects that can reach the given store object via paths of references.
|
||||
|
||||
> **Note**
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Self-references however cannot be referred to by their path, because we are in t
|
|||
> As far as we know, this is equivalent to finding a hash collision.
|
||||
|
||||
Instead we have a "has self-reference" boolean, which ends up affecting the digest:
|
||||
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
|
||||
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurrence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
|
||||
The hashes of these modified input streams are used instead.
|
||||
|
||||
When validating the content address of a store object after the fact, the above process works as written.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue