chore: rebrand Nix to Lix when it makes sense
Here's my guide so far:
$ rg '((?!(recursive).*) Nix
(?!(daemon|store|expression|Rocks!|Packages|language|derivation|archive|account|user|sandbox|flake).*))'
-g '!doc/' --pcre2
All items from this query have been tackled. For the documentation side:
that's for lix-project/lix#162.
Additionally, all remaining references to github.com/NixOS/nix which
were not relevant were also replaced.
Fixes: lix-project/lix#148.
Fixes: lix-project/lix#162.
Change-Id: Ib3451fae5cb8ab8cd9ac9e4e4551284ee6794545
Signed-off-by: Raito Bezarius <raito@lix.systems>
This commit is contained in:
parent
5312e60be6
commit
b8cb7abcf0
|
@ -6,14 +6,14 @@ Read more about us at https://lix.systems.
|
|||
|
||||
## Installation
|
||||
|
||||
On Linux and macOS the easiest way to install Nix is to run the following shell command
|
||||
On Linux and macOS the easiest way to install Lix is to run the following shell command
|
||||
(as a user other than root):
|
||||
|
||||
```console
|
||||
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
|
||||
```
|
||||
|
||||
For systems that **already have Nix installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
For systems that **already have a Nix implementation installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
|
||||
## Building And Developing
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ You can also build Lix for one of the [supported platforms](#platforms).
|
|||
|
||||
Lix can be built for various platforms, as specified in [`flake.nix`]:
|
||||
|
||||
[`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix
|
||||
[`flake.nix`]: https://git.lix.systems/lix-project/lix/src/branch/main/flake.nix
|
||||
|
||||
- `x86_64-linux`
|
||||
- `x86_64-darwin`
|
||||
|
|
|
@ -1,13 +1,13 @@
|
|||
# Obtaining the Source
|
||||
|
||||
The most recent sources of Nix can be obtained from its [Git
|
||||
repository](https://github.com/NixOS/nix). For example, the following
|
||||
The most recent sources of Lix can be obtained from its [Git
|
||||
repository](https://git.lix.systems/lix-project/lix). For example, the following
|
||||
command will check out the latest revision into a directory called
|
||||
`nix`:
|
||||
|
||||
```console
|
||||
$ git clone https://github.com/NixOS/nix
|
||||
$ git clone https://git.lix.systems/lix-project/lix
|
||||
```
|
||||
|
||||
Likewise, specific releases can be obtained from the
|
||||
[tags](https://github.com/NixOS/nix/tags) of the repository.
|
||||
[tags](https://git.lix.systems/lix-project/lix/tags) of the repository.
|
||||
|
|
|
@ -22,7 +22,7 @@ to subsequent chapters.
|
|||
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
|
||||
```
|
||||
|
||||
For systems that **already have Nix installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
For systems that **already have a Nix implementation installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
|
||||
|
||||
The install script will use `sudo`, so make sure you have sufficient rights.
|
||||
|
||||
|
|
|
@ -240,7 +240,7 @@
|
|||
system: binaryTarball nixpkgsFor.${system}.native.nix nixpkgsFor.${system}.native
|
||||
);
|
||||
|
||||
# docker image with Nix inside
|
||||
# docker image with Lix inside
|
||||
dockerImage = lib.genAttrs linux64BitSystems (system: self.packages.${system}.dockerImage);
|
||||
|
||||
# API docs for Nix's unstable internal C++ interfaces.
|
||||
|
@ -336,7 +336,7 @@
|
|||
};
|
||||
in
|
||||
pkgs.runCommand "docker-image-tarball-${version}"
|
||||
{ meta.description = "Docker image with Nix for ${system}"; }
|
||||
{ meta.description = "Docker image with Lix for ${system}"; }
|
||||
''
|
||||
mkdir -p $out/nix-support
|
||||
image=$out/image.tar.gz
|
||||
|
|
|
@ -13,7 +13,7 @@ let
|
|||
];
|
||||
};
|
||||
|
||||
meta.description = "Distribution-independent Nix bootstrap binaries for ${system}";
|
||||
meta.description = "Distribution-independent Lix bootstrap binaries for ${system}";
|
||||
in
|
||||
buildPackages.runCommand "nix-binary-tarball-${version}" { inherit meta; } ''
|
||||
cp ${installerClosureInfo}/registration $TMPDIR/reginfo
|
||||
|
|
|
@ -29,7 +29,7 @@ NEED_PROG(xz, xz)
|
|||
AC_MSG_CHECKING([whether Perl is recent enough])
|
||||
if ! $perl -e 'open(FOO, "-|", "true"); while (<FOO>) { print; }; close FOO or die;'; then
|
||||
AC_MSG_RESULT(no)
|
||||
AC_MSG_ERROR([Your Perl version is too old. Nix requires Perl 5.8.0 or newer.])
|
||||
AC_MSG_ERROR([Your Perl version is too old. Lix requires Perl 5.8.0 or newer.])
|
||||
fi
|
||||
AC_MSG_RESULT(yes)
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ MixEvalArgs::MixEvalArgs()
|
|||
-I /etc/nixos
|
||||
```
|
||||
|
||||
will cause Nix to look for paths relative to `/home/eelco/Dev` and
|
||||
will cause Lix to look for paths relative to `/home/eelco/Dev` and
|
||||
`/etc/nixos`, in that order. This is equivalent to setting the
|
||||
`NIX_PATH` environment variable to
|
||||
|
||||
|
@ -61,7 +61,7 @@ MixEvalArgs::MixEvalArgs()
|
|||
-I /etc/nixos
|
||||
```
|
||||
|
||||
will cause Nix to search for `<nixpkgs/path>` in
|
||||
will cause Lix to search for `<nixpkgs/path>` in
|
||||
`/home/eelco/Dev/nixpkgs-branch/path` and `/etc/nixos/nixpkgs/path`.
|
||||
|
||||
If a path in the Nix search path starts with `http://` or `https://`,
|
||||
|
@ -73,7 +73,7 @@ MixEvalArgs::MixEvalArgs()
|
|||
-I nixpkgs=https://github.com/NixOS/nixpkgs/archive/master.tar.gz
|
||||
```
|
||||
|
||||
tells Nix to download and use the current contents of the `master`
|
||||
tells Lix to download and use the current contents of the `master`
|
||||
branch in the `nixpkgs` repository.
|
||||
|
||||
The URLs of the tarballs from the official `nixos.org` channels
|
||||
|
|
|
@ -71,8 +71,8 @@ struct EvalSettings : Config
|
|||
Setting<bool> enableImportFromDerivation{
|
||||
this, true, "allow-import-from-derivation",
|
||||
R"(
|
||||
By default, Nix allows you to `import` from a derivation, allowing
|
||||
building at evaluation time. With this option set to false, Nix will
|
||||
By default, Lix allows you to `import` from a derivation, allowing
|
||||
building at evaluation time. With this option set to false, Lix will
|
||||
throw an error when evaluating an expression that uses this feature,
|
||||
allowing users to ensure their evaluation will not require any
|
||||
builds to take place.
|
||||
|
|
|
@ -51,7 +51,7 @@ static void runFetchClosureWithRewrite(EvalState & state, const PosIdx pos, Stor
|
|||
throw Error({
|
||||
.msg = HintFmt(
|
||||
"The 'toPath' value '%s' is input-addressed, so it can't possibly be the result of rewriting to a content-addressed path.\n\n"
|
||||
"Set 'toPath' to an empty string to make Nix report the correct content-addressed path.",
|
||||
"Set 'toPath' to an empty string to make Lix report the correct content-addressed path.",
|
||||
state.store->printStorePath(toPath)),
|
||||
.pos = state.positions[pos]
|
||||
});
|
||||
|
@ -271,7 +271,7 @@ static RegisterPrimOp primop_fetchClosure({
|
|||
```
|
||||
|
||||
It is possible to fetch an [input-addressed store path](@docroot@/glossary.md#gloss-input-addressed-store-object) and return it as is.
|
||||
However, this is the least preferred way of invoking `fetchClosure`, because it requires that the input-addressed paths are trusted by the Nix configuration.
|
||||
However, this is the least preferred way of invoking `fetchClosure`, because it requires that the input-addressed paths are trusted by the Lix configuration.
|
||||
|
||||
**`builtins.storePath`**
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ MixCommonArgs::MixCommonArgs(const std::string & programName)
|
|||
|
||||
addFlag({
|
||||
.longName = "option",
|
||||
.description = "Set the Nix configuration setting *name* to *value* (overriding `nix.conf`).",
|
||||
.description = "Set the Lix configuration setting *name* to *value* (overriding `nix.conf`).",
|
||||
.category = miscCategory,
|
||||
.labels = {"name", "value"},
|
||||
.handler = {[this](std::string name, std::string value) {
|
||||
|
|
|
@ -124,7 +124,7 @@ void detectStackOverflow();
|
|||
*
|
||||
* This is called by the handler installed by detectStackOverflow().
|
||||
*
|
||||
* This gives Nix library consumers a limit opportunity to report the error
|
||||
* This gives Lix library consumers a limit opportunity to report the error
|
||||
* condition. The handler should exit the process.
|
||||
* See defaultStackOverflowHandler() for a reference implementation.
|
||||
*
|
||||
|
|
|
@ -243,7 +243,7 @@ struct ClientSettings
|
|||
} else if (name == settings.pluginFiles.name) {
|
||||
if (tokenizeString<Paths>(value) != settings.pluginFiles.get())
|
||||
warn("Ignoring the client-specified plugin-files.\n"
|
||||
"The client specifying plugins to the daemon never made sense, and was removed in Nix >=2.14.");
|
||||
"The client specifying plugins to the daemon never made sense, and was removed in Nix.");
|
||||
}
|
||||
else if (trusted
|
||||
|| name == settings.buildTimeout.name
|
||||
|
|
|
@ -40,12 +40,12 @@ struct FileTransferSettings : Config
|
|||
this, 300, "stalled-download-timeout",
|
||||
R"(
|
||||
The timeout (in seconds) for receiving data from servers
|
||||
during download. Nix cancels idle downloads after this
|
||||
during download. Lix cancels idle downloads after this
|
||||
timeout's duration.
|
||||
)"};
|
||||
|
||||
Setting<unsigned int> tries{this, 5, "download-attempts",
|
||||
"How often Nix will attempt to download a file before giving up."};
|
||||
"How often Lix will attempt to download a file before giving up."};
|
||||
};
|
||||
|
||||
extern FileTransferSettings fileTransferSettings;
|
||||
|
|
|
@ -87,7 +87,7 @@ Settings::Settings()
|
|||
|
||||
/* Set the build hook location
|
||||
|
||||
For builds we perform a self-invocation, so Nix has to be self-aware.
|
||||
For builds we perform a self-invocation, so Lix has to be self-aware.
|
||||
That is, it has to know where it is installed. We don't think it's sentient.
|
||||
|
||||
Normally, nix is installed according to `nixBinDir`, which is set at compile time,
|
||||
|
@ -101,7 +101,7 @@ Settings::Settings()
|
|||
current executable, using `getSelfExe()`.
|
||||
|
||||
As a last resort, we resort to `PATH`. Hopefully we find a `nix` there that's compatible.
|
||||
If you're porting Nix to a new platform, that might be good enough for a while, but
|
||||
If you're porting Lix to a new platform, that might be good enough for a while, but
|
||||
you'll want to improve `getSelfExe()` to work on your platform.
|
||||
*/
|
||||
std::string nixExePath = nixBinDir + "/nix";
|
||||
|
|
|
@ -131,7 +131,7 @@ public:
|
|||
Setting<bool> tryFallback{
|
||||
this, false, "fallback",
|
||||
R"(
|
||||
If set to `true`, Nix will fall back to building from source if a
|
||||
If set to `true`, Lix will fall back to building from source if a
|
||||
binary substitute fails. This is equivalent to the `--fallback`
|
||||
flag. The default is `false`.
|
||||
)",
|
||||
|
@ -149,9 +149,9 @@ public:
|
|||
MaxBuildJobsSetting maxBuildJobs{
|
||||
this, 1, "max-jobs",
|
||||
R"(
|
||||
This option defines the maximum number of jobs that Nix will try to
|
||||
This option defines the maximum number of jobs that Lix will try to
|
||||
build in parallel. The default is `1`. The special value `auto`
|
||||
causes Nix to use the number of CPUs in your system. `0` is useful
|
||||
causes Lix to use the number of CPUs in your system. `0` is useful
|
||||
when using remote builders to prevent any local builds (except for
|
||||
`preferLocalBuild` derivation attribute which executes locally
|
||||
regardless). It can be overridden using the `--max-jobs` (`-j`)
|
||||
|
@ -195,11 +195,11 @@ public:
|
|||
Setting<std::string> thisSystem{
|
||||
this, SYSTEM, "system",
|
||||
R"(
|
||||
The system type of the current Nix installation.
|
||||
Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in [`extra-platforms`](#conf-extra-platforms).
|
||||
The system type of the current Lix installation.
|
||||
Lix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in [`extra-platforms`](#conf-extra-platforms).
|
||||
|
||||
The default value is set when Nix itself is compiled for the system it will run on.
|
||||
The following system types are widely used, as [Nix is actively supported on these platforms](@docroot@/contributing/hacking.md#platforms):
|
||||
The default value is set when Lix itself is compiled for the system it will run on.
|
||||
The following system types are widely used, as [Lix is actively supported on these platforms](@docroot@/contributing/hacking.md#platforms):
|
||||
|
||||
- `x86_64-linux`
|
||||
- `x86_64-darwin`
|
||||
|
@ -210,7 +210,7 @@ public:
|
|||
- `armv7l-linux`
|
||||
|
||||
In general, you do not have to modify this setting.
|
||||
While you can force Nix to run a Darwin-specific `builder` executable on a Linux machine, the result would obviously be wrong.
|
||||
While you can force Lix to run a Darwin-specific `builder` executable on a Linux machine, the result would obviously be wrong.
|
||||
|
||||
This value is available in the Nix language as
|
||||
[`builtins.currentSystem`](@docroot@/language/builtin-constants.md#builtins-currentSystem)
|
||||
|
@ -252,8 +252,8 @@ public:
|
|||
R"(
|
||||
The path to the helper program that executes remote builds.
|
||||
|
||||
Nix communicates with the build hook over `stdio` using a custom protocol to request builds that cannot be performed directly by the Nix daemon.
|
||||
The default value is the internal Nix binary that implements remote building.
|
||||
Lix communicates with the build hook over `stdio` using a custom protocol to request builds that cannot be performed directly by the Nix daemon.
|
||||
The default value is the internal Lix binary that implements remote building.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
|
@ -270,7 +270,7 @@ public:
|
|||
Setting<bool> alwaysAllowSubstitutes{
|
||||
this, false, "always-allow-substitutes",
|
||||
R"(
|
||||
If set to `true`, Nix will ignore the `allowSubstitutes` attribute in
|
||||
If set to `true`, Lix will ignore the `allowSubstitutes` attribute in
|
||||
derivations and always attempt to use available substituters.
|
||||
For more information on `allowSubstitutes`, see [the manual chapter on advanced attributes](../language/advanced-attributes.md).
|
||||
)"};
|
||||
|
@ -278,7 +278,7 @@ public:
|
|||
Setting<bool> buildersUseSubstitutes{
|
||||
this, false, "builders-use-substitutes",
|
||||
R"(
|
||||
If set to `true`, Nix will instruct remote build machines to use
|
||||
If set to `true`, Lix will instruct remote build machines to use
|
||||
their own binary substitutes if available. In practical terms, this
|
||||
means that remote hosts will fetch as many build dependencies as
|
||||
possible from their own substitutes (e.g, from `cache.nixos.org`),
|
||||
|
@ -317,7 +317,7 @@ public:
|
|||
Setting<bool> useSubstitutes{
|
||||
this, true, "substitute",
|
||||
R"(
|
||||
If set to `true` (default), Nix will use binary substitutes if
|
||||
If set to `true` (default), Lix will use binary substitutes if
|
||||
available. This option can be disabled to force building from
|
||||
source.
|
||||
)",
|
||||
|
@ -326,9 +326,9 @@ public:
|
|||
Setting<std::string> buildUsersGroup{
|
||||
this, "", "build-users-group",
|
||||
R"(
|
||||
This options specifies the Unix group containing the Nix build user
|
||||
accounts. In multi-user Nix installations, builds should not be
|
||||
performed by the Nix account since that would allow users to
|
||||
This options specifies the Unix group containing the Lix build user
|
||||
accounts. In multi-user Lix installations, builds should not be
|
||||
performed by the Lix account since that would allow users to
|
||||
arbitrarily modify the Nix store and database by supplying specially
|
||||
crafted builders; and they cannot be performed by the calling user
|
||||
since that would allow him/her to influence the build result.
|
||||
|
@ -338,11 +338,11 @@ public:
|
|||
of the group specified here (as listed in `/etc/group`). Those user
|
||||
accounts should not be used for any other purpose\!
|
||||
|
||||
Nix will never run two builds under the same user account at the
|
||||
Lix will never run two builds under the same user account at the
|
||||
same time. This is to prevent an obvious security hole: a malicious
|
||||
user writing a Nix expression that modifies the build result of a
|
||||
legitimate Nix expression being built by another user. Therefore it
|
||||
is good to have as many Nix build user accounts as you can spare.
|
||||
is good to have as many Lix build user accounts as you can spare.
|
||||
(Remember: uids are cheap.)
|
||||
|
||||
The build users should have permission to create files in the Nix
|
||||
|
@ -351,7 +351,7 @@ public:
|
|||
and its mode should be `1775`.
|
||||
|
||||
If the build users group is empty, builds will be performed under
|
||||
the uid of the Nix process (that is, the uid of the caller if
|
||||
the uid of the Lix process (that is, the uid of the caller if
|
||||
`NIX_REMOTE` is empty, the uid under which the Nix daemon runs if
|
||||
`NIX_REMOTE` is `daemon`). Obviously, this should not be used
|
||||
with a nix daemon accessible to untrusted clients.
|
||||
|
@ -405,7 +405,7 @@ public:
|
|||
Setting<bool> keepLog{
|
||||
this, true, "keep-build-log",
|
||||
R"(
|
||||
If set to `true` (the default), Nix will write the build log of a
|
||||
If set to `true` (the default), Lix will write the build log of a
|
||||
derivation (i.e. the standard output and error of its builder) to
|
||||
the directory `/nix/var/log/nix/drvs`. The build log can be
|
||||
retrieved using the command `nix-store -l path`.
|
||||
|
@ -468,7 +468,7 @@ public:
|
|||
Setting<bool> autoOptimiseStore{
|
||||
this, false, "auto-optimise-store",
|
||||
R"(
|
||||
If set to `true`, Nix automatically detects files in the store
|
||||
If set to `true`, Lix automatically detects files in the store
|
||||
that have identical contents, and replaces them with hard links to
|
||||
a single copy. This saves disk space. If set to `false` (the
|
||||
default), you can still run `nix-store --optimise` to get rid of
|
||||
|
@ -519,7 +519,7 @@ public:
|
|||
network).
|
||||
|
||||
Currently, sandboxing only work on Linux and macOS. The use of a
|
||||
sandbox requires that Nix is run as root (so you should use the
|
||||
sandbox requires that Lix is run as root (so you should use the
|
||||
“build users” feature to perform the actual builds under different
|
||||
users than root).
|
||||
|
||||
|
@ -545,7 +545,7 @@ public:
|
|||
If the source is in the Nix store, then its closure will be added to
|
||||
the sandbox as well.
|
||||
|
||||
Depending on how Nix was built, the default value for this option
|
||||
Depending on how Lix was built, the default value for this option
|
||||
may be empty or provide `/bin/sh` as a bind-mount of `bash`.
|
||||
)",
|
||||
{"build-chroot-dirs", "build-sandbox-paths"}};
|
||||
|
@ -556,7 +556,7 @@ public:
|
|||
Setting<bool> requireDropSupplementaryGroups{this, getuid() == 0, "require-drop-supplementary-groups",
|
||||
R"(
|
||||
Following the principle of least privilege,
|
||||
Nix will attempt to drop supplementary groups when building with sandboxing.
|
||||
Lix will attempt to drop supplementary groups when building with sandboxing.
|
||||
|
||||
However this can fail under some circumstances.
|
||||
For example, if the user lacks the `CAP_SETGID` capability.
|
||||
|
@ -642,7 +642,7 @@ public:
|
|||
A whitespace-separated list of public keys.
|
||||
|
||||
At least one of the following condition must be met
|
||||
for Nix to accept copying a store object from another
|
||||
for Lix to accept copying a store object from another
|
||||
Nix store (such as a substituter):
|
||||
|
||||
- the store object has been signed using a key in the trusted keys list
|
||||
|
@ -665,14 +665,14 @@ public:
|
|||
this, 60 * 60, "tarball-ttl",
|
||||
R"(
|
||||
The number of seconds a downloaded tarball is considered fresh. If
|
||||
the cached tarball is stale, Nix will check whether it is still up
|
||||
to date using the ETag header. Nix will download a new version if
|
||||
the cached tarball is stale, Lix will check whether it is still up
|
||||
to date using the ETag header. Lix will download a new version if
|
||||
the ETag header is unsupported, or the cached ETag doesn't match.
|
||||
|
||||
Setting the TTL to `0` forces Nix to always check if the tarball is
|
||||
Setting the TTL to `0` forces Lix to always check if the tarball is
|
||||
up to date.
|
||||
|
||||
Nix caches tarballs in `$XDG_CACHE_HOME/nix/tarballs`.
|
||||
Lix caches tarballs in `$XDG_CACHE_HOME/nix/tarballs`.
|
||||
|
||||
Files fetched via `NIX_PATH`, `fetchGit`, `fetchMercurial`,
|
||||
`fetchTarball`, and `fetchurl` respect this TTL.
|
||||
|
@ -701,7 +701,7 @@ public:
|
|||
R"(
|
||||
System types of executables that can be run on this machine.
|
||||
|
||||
Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in the [`system` option](#conf-system).
|
||||
Lix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in the [`system` option](#conf-system).
|
||||
|
||||
Setting this can be useful to build derivations locally on compatible machines:
|
||||
- `i686-linux` executables can be run on `x86_64-linux` machines (set by default)
|
||||
|
@ -748,16 +748,16 @@ public:
|
|||
"substituters",
|
||||
R"(
|
||||
A list of [URLs of Nix stores](@docroot@/command-ref/new-cli/nix3-help-stores.md#store-url-format) to be used as substituters, separated by whitespace.
|
||||
A substituter is an additional [store](@docroot@/glossary.md#gloss-store) from which Nix can obtain [store objects](@docroot@/glossary.md#gloss-store-object) instead of building them.
|
||||
A substituter is an additional [store](@docroot@/glossary.md#gloss-store) from which Lix can obtain [store objects](@docroot@/glossary.md#gloss-store-object) instead of building them.
|
||||
|
||||
Substituters are tried based on their priority value, which each substituter can set independently.
|
||||
Lower value means higher priority.
|
||||
The default is `https://cache.nixos.org`, which has a priority of 40.
|
||||
|
||||
At least one of the following conditions must be met for Nix to use a substituter:
|
||||
At least one of the following conditions must be met for Lix to use a substituter:
|
||||
|
||||
- The substituter is in the [`trusted-substituters`](#conf-trusted-substituters) list
|
||||
- The user calling Nix is in the [`trusted-users`](#conf-trusted-users) list
|
||||
- The user calling Lix is in the [`trusted-users`](#conf-trusted-users) list
|
||||
|
||||
In addition, each store path should be trusted as described in [`trusted-public-keys`](#conf-trusted-public-keys)
|
||||
)",
|
||||
|
@ -866,13 +866,13 @@ public:
|
|||
this, 0, "download-speed",
|
||||
R"(
|
||||
Specify the maximum transfer rate in kilobytes per second you want
|
||||
Nix to use for downloads.
|
||||
Lix to use for downloads.
|
||||
)"};
|
||||
|
||||
Setting<std::string> netrcFile{
|
||||
this, fmt("%s/%s", nixConfDir, "netrc"), "netrc-file",
|
||||
R"(
|
||||
If set to an absolute path to a `netrc` file, Nix will use the HTTP
|
||||
If set to an absolute path to a `netrc` file, Lix will use the HTTP
|
||||
authentication credentials in this file when trying to download from
|
||||
a remote host through HTTP or HTTPS. Defaults to
|
||||
`$NIX_CONF_DIR/netrc`.
|
||||
|
@ -898,7 +898,7 @@ public:
|
|||
this, getDefaultSSLCertFile(), "ssl-cert-file",
|
||||
R"(
|
||||
The path of a file containing CA certificates used to
|
||||
authenticate `https://` downloads. Nix by default will use
|
||||
authenticate `https://` downloads. Lix by default will use
|
||||
the first of the following files that exists:
|
||||
|
||||
1. `/etc/ssl/certs/ca-certificates.crt`
|
||||
|
@ -915,7 +915,7 @@ public:
|
|||
Setting<StringSet> ignoredAcls{
|
||||
this, {"security.selinux", "system.nfs4_acl", "security.csm"}, "ignored-acls",
|
||||
R"(
|
||||
A list of ACLs that should be ignored, normally Nix attempts to
|
||||
A list of ACLs that should be ignored, normally Lix attempts to
|
||||
remove all ACLs from files and directories in the Nix store, but
|
||||
some ACLs like `security.selinux` or `system.nfs4_acl` can't be
|
||||
removed even by root. Therefore it's best to just ignore them.
|
||||
|
@ -926,7 +926,7 @@ public:
|
|||
this, {}, "hashed-mirrors",
|
||||
R"(
|
||||
A list of web servers used by `builtins.fetchurl` to obtain files by
|
||||
hash. Given a hash type *ht* and a base-16 hash *h*, Nix will try to
|
||||
hash. Given a hash type *ht* and a base-16 hash *h*, Lix will try to
|
||||
download the file from *hashed-mirror*/*ht*/*h*. This allows files to
|
||||
be downloaded even if they have disappeared from their original URI.
|
||||
For example, given an example mirror `http://tarballs.nixos.org/`,
|
||||
|
@ -939,7 +939,7 @@ public:
|
|||
}
|
||||
```
|
||||
|
||||
Nix will attempt to download this file from
|
||||
Lix will attempt to download this file from
|
||||
`http://tarballs.nixos.org/sha256/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae`
|
||||
first. If it is not available there, if will try the original URI.
|
||||
)"};
|
||||
|
@ -948,7 +948,7 @@ public:
|
|||
this, 0, "min-free",
|
||||
R"(
|
||||
When free disk space in `/nix/store` drops below `min-free` during a
|
||||
build, Nix performs a garbage-collection until `max-free` bytes are
|
||||
build, Lix performs a garbage-collection until `max-free` bytes are
|
||||
available or there is no more garbage. A value of `0` (the default)
|
||||
disables this feature.
|
||||
)"};
|
||||
|
@ -983,7 +983,7 @@ public:
|
|||
itself, they must be DSOs compatible with the instance of Nix
|
||||
running at the time (i.e. compiled against the same headers, not
|
||||
linked to any incompatible libraries). They should not be linked to
|
||||
any Nix libs directly, as those will be available already at load
|
||||
any Lix libs directly, as those will be available already at load
|
||||
time.
|
||||
|
||||
If an entry in the list is a directory, all files in the directory
|
||||
|
@ -996,7 +996,7 @@ public:
|
|||
Setting<bool> allowSymlinkedStore{
|
||||
this, false, "allow-symlinked-store",
|
||||
R"(
|
||||
If set to `true`, Nix will stop complaining if the store directory
|
||||
If set to `true`, Lix will stop complaining if the store directory
|
||||
(typically /nix/store) contains symlink components.
|
||||
|
||||
This risks making some builds "impure" because builders sometimes
|
||||
|
@ -1009,13 +1009,13 @@ public:
|
|||
Setting<bool> useXDGBaseDirectories{
|
||||
this, false, "use-xdg-base-directories",
|
||||
R"(
|
||||
If set to `true`, Nix will conform to the [XDG Base Directory Specification] for files in `$HOME`.
|
||||
If set to `true`, Lix will conform to the [XDG Base Directory Specification] for files in `$HOME`.
|
||||
The environment variables used to implement this are documented in the [Environment Variables section](@docroot@/command-ref/env-common.md).
|
||||
|
||||
[XDG Base Directory Specification]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
|
||||
|
||||
> **Warning**
|
||||
> This changes the location of some well-known symlinks that Nix creates, which might break tools that rely on the old, non-XDG-conformant locations.
|
||||
> This changes the location of some well-known symlinks that Lix creates, which might break tools that rely on the old, non-XDG-conformant locations.
|
||||
|
||||
In particular, the following locations change:
|
||||
|
||||
|
@ -1025,7 +1025,7 @@ public:
|
|||
| `~/.nix-defexpr` | `$XDG_STATE_HOME/nix/defexpr` |
|
||||
| `~/.nix-channels` | `$XDG_STATE_HOME/nix/channels` |
|
||||
|
||||
If you already have Nix installed and are using [profiles](@docroot@/package-management/profiles.md) or [channels](@docroot@/command-ref/nix-channel.md), you should migrate manually when you enable this option.
|
||||
If you already have Lix installed and are using [profiles](@docroot@/package-management/profiles.md) or [channels](@docroot@/command-ref/nix-channel.md), you should migrate manually when you enable this option.
|
||||
If `$XDG_STATE_HOME` is not set, use `$HOME/.local/state/nix` instead of `$XDG_STATE_HOME/nix`.
|
||||
This can be achieved with the following shell commands:
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
* a glibc git checkout via `rg --pcre2 'define __NR_fchmodat2 (?!452)'`.
|
||||
*
|
||||
* The problem is that glibc 2.39 and libseccomp 2.5.5 are needed to
|
||||
* get the syscall number. However, a Nix built against nixpkgs 23.11
|
||||
* get the syscall number. However, a Lix built against nixpkgs 23.11
|
||||
* (glibc 2.38) should still have the issue fixed without depending
|
||||
* on the build environment.
|
||||
*
|
||||
|
|
|
@ -18,12 +18,12 @@ struct LocalFSStoreConfig : virtual StoreConfig
|
|||
const PathSetting stateDir{this,
|
||||
rootDir.get() ? *rootDir.get() + "/nix/var/nix" : settings.nixStateDir,
|
||||
"state",
|
||||
"Directory where Nix will store state."};
|
||||
"Directory where Lix will store state."};
|
||||
|
||||
const PathSetting logDir{this,
|
||||
rootDir.get() ? *rootDir.get() + "/nix/var/log/nix" : settings.nixLogDir,
|
||||
"log",
|
||||
"directory where Nix will store log files."};
|
||||
"directory where Lix will store log files."};
|
||||
|
||||
const PathSetting realStoreDir{this,
|
||||
rootDir.get() ? *rootDir.get() + "/nix/store" : storeDir, "real",
|
||||
|
|
|
@ -313,13 +313,13 @@ LocalStore::LocalStore(const Params & params)
|
|||
throw Error(
|
||||
"Your Nix store has a database in Berkeley DB format,\n"
|
||||
"which is no longer supported. To convert to the new format,\n"
|
||||
"please upgrade Nix to version 0.12 first.");
|
||||
"please use the original Nix version 0.12 first.");
|
||||
|
||||
if (curSchema < 6)
|
||||
throw Error(
|
||||
"Your Nix store has a database in flat file format,\n"
|
||||
"which is no longer supported. To convert to the new format,\n"
|
||||
"please upgrade Nix to version 1.11 first.");
|
||||
"please use the original Nix version 1.11 first.");
|
||||
|
||||
if (!lockFile(globalLock.get(), ltWrite, false)) {
|
||||
printInfo("waiting for exclusive access to the Nix store...");
|
||||
|
|
|
@ -23,6 +23,9 @@ namespace nix {
|
|||
* 0.7. Version 2 was Nix 0.8 and 0.9. Version 3 is Nix 0.10.
|
||||
* Version 4 is Nix 0.11. Version 5 is Nix 0.12-0.16. Version 6 is
|
||||
* Nix 1.0. Version 7 is Nix 1.3. Version 10 is 2.0.
|
||||
*
|
||||
* Lix started at 2.90, it cannot ever go past version 10 (Nix 2.18),
|
||||
* since doing so will break compatibility with future CppNix versions.
|
||||
*/
|
||||
const int nixSchemaVersion = 10;
|
||||
|
||||
|
@ -49,7 +52,7 @@ struct LocalStoreConfig : virtual LocalFSStoreConfig
|
|||
R"(
|
||||
Allow this store to be opened when its [database](@docroot@/glossary.md#gloss-nix-database) is on a read-only filesystem.
|
||||
|
||||
Normally Nix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
|
||||
Normally Lix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
|
||||
|
||||
Enable read-only mode to disable locking and open the SQLite database with the [`immutable` parameter](https://www.sqlite.org/c3ref/open.html) set.
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ struct Generation
|
|||
* of the generation.
|
||||
*
|
||||
* These store paths / objects are not unique to the generation
|
||||
* within a profile. Nix tries to ensure successive generations have
|
||||
* within a profile. Lix tries to ensure successive generations have
|
||||
* distinct contents to avoid bloat, but nothing stops two
|
||||
* non-adjacent generations from having the same contents.
|
||||
*
|
||||
|
|
|
@ -196,7 +196,7 @@ struct S3BinaryCacheStoreConfig : virtual BinaryCacheStoreConfig
|
|||
const Setting<std::string> profile{this, "", "profile",
|
||||
R"(
|
||||
The name of the AWS configuration profile to use. By default
|
||||
Nix will use the `default` profile.
|
||||
Lix will use the `default` profile.
|
||||
)"};
|
||||
|
||||
const Setting<std::string> region{this, Aws::Region::US_EAST_1, "region",
|
||||
|
|
|
@ -1379,9 +1379,9 @@ std::shared_ptr<Store> openFromNonUri(const std::string & uri, const Store::Para
|
|||
} catch (Error & e) {
|
||||
return LocalStore::makeLocalStore(params);
|
||||
}
|
||||
warn("'%s' does not exist, so Nix will use '%s' as a chroot store", stateDir, chrootStore);
|
||||
warn("'%s' does not exist, so Lix will use '%s' as a chroot store", stateDir, chrootStore);
|
||||
} else
|
||||
debug("'%s' does not exist, so Nix will use '%s' as a chroot store", stateDir, chrootStore);
|
||||
debug("'%s' does not exist, so Lix will use '%s' as a chroot store", stateDir, chrootStore);
|
||||
Store::Params chrootStoreParams;
|
||||
chrootStoreParams["root"] = chrootStore;
|
||||
// FIXME? this ignores *all* store parameters passed to this function?
|
||||
|
|
|
@ -74,7 +74,7 @@ void WorkerProto::Serialise<DerivedPath>::write(const Store & store, WorkerProto
|
|||
GET_PROTOCOL_MINOR(conn.version));
|
||||
},
|
||||
[&](std::monostate) {
|
||||
throw Error("wanted to build a derivation that is itself a build product, but protocols do not support that. Try upgrading the Nix on the other end of this connection");
|
||||
throw Error("wanted to build a derivation that is itself a build product, but protocols do not support that. Try upgrading the Nix implementation on the other end of this connection");
|
||||
},
|
||||
}, sOrDrvPath);
|
||||
}
|
||||
|
|
|
@ -13,7 +13,7 @@
|
|||
namespace nix {
|
||||
|
||||
/**
|
||||
* The Config class provides Nix runtime configurations.
|
||||
* The Config class provides Lix runtime configurations.
|
||||
*
|
||||
* What is a Configuration?
|
||||
* A collection of uniquely named Settings.
|
||||
|
|
|
@ -293,7 +293,7 @@ std::set<ExperimentalFeature> parseFeatures(const std::set<std::string> & rawFea
|
|||
}
|
||||
|
||||
MissingExperimentalFeature::MissingExperimentalFeature(ExperimentalFeature feature)
|
||||
: Error("experimental Nix feature '%1%' is disabled; use '--extra-experimental-features %1%' to override", showExperimentalFeature(feature))
|
||||
: Error("experimental Lix feature '%1%' is disabled; use '--extra-experimental-features %1%' to override", showExperimentalFeature(feature))
|
||||
, missingFeature(feature)
|
||||
{}
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ struct LoggerSettings : Config
|
|||
Setting<bool> showTrace{
|
||||
this, false, "show-trace",
|
||||
R"(
|
||||
Whether Nix should print out a stack trace in case of Nix
|
||||
Whether Lix should print out a stack trace in case of Nix
|
||||
expression evaluation errors.
|
||||
)"};
|
||||
};
|
||||
|
|
|
@ -14,7 +14,7 @@ struct CmdConfig : virtual NixMultiCommand
|
|||
|
||||
std::string description() override
|
||||
{
|
||||
return "manipulate the Nix configuration";
|
||||
return "manipulate the Lix configuration";
|
||||
}
|
||||
|
||||
Category category() override { return catUtility; }
|
||||
|
@ -41,7 +41,7 @@ struct CmdConfigShow : Command, MixJSON
|
|||
|
||||
std::string description() override
|
||||
{
|
||||
return "show the Nix configuration or the value of a specific setting";
|
||||
return "show the Lix configuration or the value of a specific setting";
|
||||
}
|
||||
|
||||
Category category() override { return catUtility; }
|
||||
|
|
|
@ -77,7 +77,7 @@ R""(
|
|||
# Description
|
||||
|
||||
`nix develop` starts a `bash` shell that provides an interactive build
|
||||
environment nearly identical to what Nix would use to build
|
||||
environment nearly identical to what Lix would use to build
|
||||
[*installable*](./nix.md#installables). Inside this shell, environment variables and shell
|
||||
functions are set up so that you can interactively and incrementally
|
||||
build your package.
|
||||
|
|
|
@ -22,7 +22,7 @@ This command verifies that the flake specified by flake reference
|
|||
that the derivations specified by the flake's `checks` output can be
|
||||
built successfully.
|
||||
|
||||
If the `keep-going` option is set to `true`, Nix will keep evaluating as much
|
||||
If the `keep-going` option is set to `true`, Lix will keep evaluating as much
|
||||
as it can and report the errors as it encounters them. Otherwise it will stop
|
||||
at the first error.
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ R""(
|
|||
>
|
||||
> When trying to refer to a flake in a subdirectory, write `./another`
|
||||
> instead of `another`.
|
||||
> Otherwise Nix will try to look up the flake in the registry.
|
||||
> Otherwise Lix will try to look up the flake in the registry.
|
||||
|
||||
# Description
|
||||
|
||||
|
|
|
@ -39,7 +39,7 @@ R""(
|
|||
>
|
||||
> When trying to refer to a flake in a subdirectory, write `./another`
|
||||
> instead of `another`.
|
||||
> Otherwise Nix will try to look up the flake in the registry.
|
||||
> Otherwise Lix will try to look up the flake in the registry.
|
||||
|
||||
# Description
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ Flakes corresponding to a local path can also be referred to by a direct path re
|
|||
The semantic of such a path is as follows:
|
||||
|
||||
* If the directory is part of a Git repository, then the input will be treated as a `git+file:` URL, otherwise it will be treated as a `path:` url;
|
||||
* If the directory doesn't contain a `flake.nix` file, then Nix will search for such a file upwards in the file system hierarchy until it finds any of:
|
||||
* If the directory doesn't contain a `flake.nix` file, then Lix will search for such a file upwards in the file system hierarchy until it finds any of:
|
||||
1. The Git repository root, or
|
||||
2. The filesystem root (/), or
|
||||
3. A folder on a different mount point.
|
||||
|
@ -176,7 +176,7 @@ Currently the `type` attribute can be one of the following:
|
|||
The `ref` attribute defaults to resolving the `HEAD` reference.
|
||||
|
||||
The `rev` attribute must denote a commit that exists in the branch
|
||||
or tag specified by the `ref` attribute, since Nix doesn't do a full
|
||||
or tag specified by the `ref` attribute, since Lix doesn't do a full
|
||||
clone of the remote repository by default (and the Git protocol
|
||||
doesn't allow fetching a `rev` without a known `ref`). The default
|
||||
is the commit currently pointed to by `ref`.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
R"(
|
||||
|
||||
Nix supports different types of stores. These are described below.
|
||||
Lix supports different types of stores. These are described below.
|
||||
|
||||
## Store URL format
|
||||
|
||||
|
@ -22,11 +22,11 @@ instance,
|
|||
--store ssh://machine.example.org?ssh-key=/path/to/my/key
|
||||
```
|
||||
|
||||
tells Nix to access the store on a remote machine via the SSH
|
||||
tells Lix to access the store on a remote machine via the SSH
|
||||
protocol, using `/path/to/my/key` as the SSH private key. The
|
||||
supported settings for each store type are documented below.
|
||||
|
||||
The special store URL `auto` causes Nix to automatically select a
|
||||
The special store URL `auto` causes Lix to automatically select a
|
||||
store as follows:
|
||||
|
||||
* Use the [local store](#local-store) `/nix/store` if `/nix/var/nix`
|
||||
|
|
|
@ -26,7 +26,7 @@ R""(
|
|||
|
||||
This command prints the log of a previous build of the [*installable*](./nix.md#installables) on standard output.
|
||||
|
||||
Nix looks for build logs in two places:
|
||||
Lix looks for build logs in two places:
|
||||
|
||||
* In the directory `/nix/var/log/nix/drvs`, which contains logs for
|
||||
locally built derivations.
|
||||
|
@ -35,7 +35,7 @@ Nix looks for build logs in two places:
|
|||
should be named `<cache>/log/<base-name-of-store-path>`, where
|
||||
`store-path` is a derivation,
|
||||
e.g. `https://cache.nixos.org/log/dvmig8jgrdapvbyxb1rprckdmdqx08kv-hello-2.10.drv`.
|
||||
For non-derivation store paths, Nix will first try to determine the
|
||||
For non-derivation store paths, Lix will first try to determine the
|
||||
deriver by fetching the `.narinfo` file for this store path.
|
||||
|
||||
)""
|
||||
|
|
|
@ -41,10 +41,11 @@ R""(
|
|||
|
||||
# Description
|
||||
|
||||
Nix is a tool for building software, configurations and other
|
||||
Lix is a tool for building software, configurations and other
|
||||
artifacts in a reproducible and declarative way. For more information,
|
||||
see the [Nix homepage](https://nixos.org/) or the [Nix
|
||||
manual](https://nixos.org/manual/nix/stable/).
|
||||
see the [Lix homepage](https://lix.systems).
|
||||
|
||||
Lix is a fork of the original implementation [CppNix](https://github.com/nixos/nix).
|
||||
|
||||
# Installables
|
||||
|
||||
|
@ -68,7 +69,7 @@ The following types of installable are supported by most commands:
|
|||
- Specified with `--expr`/`-E`
|
||||
|
||||
For most commands, if no installable is specified, `.` is assumed.
|
||||
That is, Nix will operate on the default flake output attribute of the flake in the current directory.
|
||||
That is, Lix will operate on the default flake output attribute of the flake in the current directory.
|
||||
|
||||
### Flake output attribute
|
||||
|
||||
|
@ -99,7 +100,7 @@ way:
|
|||
and `RELATIVE_FLAKE_DIR_PATH` is the path (relative to the directory
|
||||
root) of the closest parent of the given path that contains a `flake.nix` within
|
||||
the git repository.
|
||||
If no such directory exists, then Nix will error-out.
|
||||
If no such directory exists, then Lix will error-out.
|
||||
|
||||
Note that the search will only include files indexed by git. In particular, files
|
||||
which are matched by `.gitignore` or have never been `git add`-ed will not be
|
||||
|
@ -120,12 +121,12 @@ way:
|
|||
- If the supplied path is not a git repository, then the url will have the form
|
||||
`path:FLAKE_DIR_PATH` where `FLAKE_DIR_PATH` is the closest parent
|
||||
of the supplied path that contains a `flake.nix` file (within the same file-system).
|
||||
If no such directory exists, then Nix will error-out.
|
||||
If no such directory exists, then Lix will error-out.
|
||||
|
||||
For example, if `/foo/bar/flake.nix` exists, then `/foo/bar/baz/` will resolve to
|
||||
`path:/foo/bar`
|
||||
|
||||
If *attrpath* is omitted, Nix tries some default values; for most
|
||||
If *attrpath* is omitted, Lix tries some default values; for most
|
||||
subcommands, the default is `packages.`*system*`.default`
|
||||
(e.g. `packages.x86_64-linux.default`), but some subcommands have
|
||||
other defaults. If *attrpath* *is* specified, *attrpath* is
|
||||
|
@ -243,7 +244,7 @@ operate are determined as follows:
|
|||
…
|
||||
```
|
||||
* If you didn't specify the desired outputs, but the derivation has an
|
||||
attribute `meta.outputsToInstall`, Nix will use those outputs. For
|
||||
attribute `meta.outputsToInstall`, Lix will use those outputs. For
|
||||
example, since the package `nixpkgs#libxml2` has this attribute:
|
||||
|
||||
```console
|
||||
|
@ -259,7 +260,7 @@ operate are determined as follows:
|
|||
|
||||
[store derivation]: ../../glossary.md#gloss-store-derivation
|
||||
|
||||
* Otherwise, Nix will use all outputs of the derivation.
|
||||
* Otherwise, Lix will use all outputs of the derivation.
|
||||
|
||||
# Nix stores
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ links to a single instance.
|
|||
|
||||
Note that you can also set `auto-optimise-store` to `true` in
|
||||
`nix.conf` to perform this optimisation incrementally whenever a new
|
||||
path is added to the Nix store. To make this efficient, Nix maintains
|
||||
path is added to the Nix store. To make this efficient, Lix maintains
|
||||
a content-addressed index of all the files in the Nix store in the
|
||||
directory `/nix/store/.links/`.
|
||||
|
||||
|
|
|
@ -25,9 +25,9 @@ R""(
|
|||
This command tests whether a particular Nix store (specified by the
|
||||
argument `--store` *url*) can be accessed. What this means is
|
||||
dependent on the type of the store. For instance, for an SSH store it
|
||||
means that Nix can connect to the specified machine.
|
||||
means that Lix can connect to the specified machine.
|
||||
|
||||
If the command succeeds, Nix returns a exit code of 0 and does not
|
||||
If the command succeeds, Lix returns a exit code of 0 and does not
|
||||
print any output.
|
||||
|
||||
)""
|
||||
|
|
|
@ -48,7 +48,7 @@ struct CmdRepl : RawInstallablesCommand
|
|||
void applyDefaultInstallables(std::vector<std::string> & rawInstallables) override
|
||||
{
|
||||
if (!experimentalFeatureSettings.isEnabled(Xp::ReplFlake) && !(file) && rawInstallables.size() >= 1) {
|
||||
warn("future versions of Nix will require using `--file` to load a file");
|
||||
warn("future versions of Lix will require using `--file` to load a file");
|
||||
if (rawInstallables.size() > 1)
|
||||
warn("more than one input file is not currently supported");
|
||||
auto filePath = rawInstallables[0].data();
|
||||
|
|
|
@ -26,7 +26,7 @@ R""(
|
|||
```
|
||||
|
||||
Note that `vim` (as of the time of writing of this page) is not an
|
||||
app but a package. Thus, Nix runs the eponymous file from the `vim`
|
||||
app but a package. Thus, Lix runs the eponymous file from the `vim`
|
||||
package.
|
||||
|
||||
* Run `vim` with arguments:
|
||||
|
|
|
@ -53,18 +53,18 @@ R""(
|
|||
|
||||
# Description
|
||||
|
||||
Nix automatically determines potential runtime dependencies between
|
||||
Lix automatically determines potential runtime dependencies between
|
||||
store paths by scanning for the *hash parts* of store paths. For
|
||||
instance, if there exists a store path
|
||||
`/nix/store/9df65igwjmf2wbw0gbrrgair6piqjgmi-glibc-2.31`, and a file
|
||||
inside another store path contains the string `9df65igw…`, then the
|
||||
latter store path *refers* to the former, and thus might need it at
|
||||
runtime. Nix always maintains the existence of the transitive closure
|
||||
runtime. Lix always maintains the existence of the transitive closure
|
||||
of a store path under the references relationship; it is therefore not
|
||||
possible to install a store path without having all of its references
|
||||
present.
|
||||
|
||||
Sometimes Nix packages end up with unexpected runtime dependencies;
|
||||
Sometimes Lix packages end up with unexpected runtime dependencies;
|
||||
for instance, a reference to a compiler might accidentally end up in a
|
||||
binary, causing the former to be in the latter's closure. This kind of
|
||||
*closure size bloat* is undesirable.
|
||||
|
|
|
@ -70,7 +70,7 @@ export _NIX_FORCE_HTTP=1
|
|||
basicDownloadTests
|
||||
|
||||
|
||||
# Test whether Nix notices if the NAR doesn't match the hash in the NAR info.
|
||||
# Test whether Lix notices if the NAR doesn't match the hash in the NAR info.
|
||||
clearStore
|
||||
|
||||
nar=$(ls $cacheDir/nar/*.nar.xz | head -n1)
|
||||
|
|
|
@ -18,7 +18,7 @@ nix-build build-hook.nix -A passthru.input2 \
|
|||
--store "$TEST_ROOT/local" \
|
||||
--option system-features bar
|
||||
|
||||
# Now when we go to build that downstream derivation, Nix will try to
|
||||
# Now when we go to build that downstream derivation, Lix will try to
|
||||
# copy our already-build `input2` to the remote store. That store object
|
||||
# is input-addressed, so this will fail.
|
||||
|
||||
|
|