When using pkgsCross with a system that ends up the same as the
localSystem, then modifications for package sets like pksgMusl need to
be done for **both** localSystem and crossSystem. Consider the following
on x86_64-linux:
pkgsCross.gnu64.pkgsMusl
Before this change, this would result in a musl buildPlatform, but a gnu
hostPlatform. This breaks the promise of "stacking" package sets on top
of each other.
After this change, it results in a musl buildPlatform and a musl
hostPlatform. This works better.
One could expect this to result in the same as pkgsCross.musl64, i.e. a
gnu buildPlatform and a musl hostPlatform, however I couldn't get this
to work without increasing memory usage for ci/eval by many, many GB.
This is caused by usage of pkgsi686Linux inside the main package set,
which follows the same hybrid pattern.
The various pkgsXYZ top-level package sets did not pass localSystem /
crossSystem to lower levels, so far. This change propagates original
arguments to lower levels, which include the overrides made by an upper
package sets.
There is an extensive test-suite to test various combinations of package
sets in pkgs/test/top-level. There are a few basic promises made:
- Package sets must be idempotent. pkgsMusl.pkgsMusl === pkgsMusl.
- Once pkgsCross is used any subsequent package sets should affect the
**host platform** and not the build platform. Examples:
- pkgsMusl.pkgsCross.aarch64-multiplatform is a cross compilation from
musl to glibc/aarch64
- pkgsCross.aarch64-multiplatform.pkgsMusl is a cross compilation to
musl/aarch64
- Modifications from an earlier layer should not be lost, unless
explicitly overwritten. Examples:
- pkgsStatic.pkgsMusl should still be static.
- pkgsStatic.pkgsCross.gnu64 should be static, but with glibc instead
of musl.
Exceptions / TODOs:
- pkgsExtraHardening is currently not idempotent, because it applies the
same flags over and over again.
Supersedes #136549Resolves#114510Resolves#212494Resolves#281596
Passing the elaborated system defeats what pkgs/top-level/default.nix
tries to do: Pass only the original args and let defaults be inferred.
The underlying problem is that lib.systems.elaborate can not deal with
arbitrary overrides, but will often return an inconsistent system
description when partially overriding some values. This becomes most
prominent if trying to override an already elaborated system.
This adds some basic tests to compose package sets. The cases that are
currently broken
are commented out, they include things like:
- pkgsStatic.pkgsMusl losing the isStatic flag
- pkgsCross.ppc64-musl.pkgsMusl losing the gcc.abi setting
- pkgsCross.mingwW64.pkgsStatic losing the config string
- pkgsLLVM.pkgsMusl losing the useLLVM flag
- pkgsLLVM.pkgsStatic losing the useLLVM flag
- pkgsLLVM.pkgsi686Linux losing the useLLVM flag
And probably more.
No change, just move appendOverlays and extend to the bottom, since they
will be changed much less often. This makes it easier to compare the
other package sets side-by-side.
